lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6934efce0707021746q133c62f5l803e5fa78b3535d9@mail.gmail.com>
Date:	Mon, 2 Jul 2007 17:46:40 -0700
From:	"Jared Hulbert" <jaredeh@...il.com>
To:	"Jörn Engel" <joern@...fs.org>
Cc:	"Christoph Hellwig" <hch@...radead.org>,
	"Nick Piggin" <npiggin@...e.de>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Linux Memory Management List" <linux-mm@...ck.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: vm/fs meetup in september?

On 7/2/07, Jörn Engel <joern@...fs.org> wrote:
> On Mon, 2 July 2007 10:44:00 -0700, Jared Hulbert wrote:
> >
> > >So what you mean is "swap on flash" ?  Defintively sounds like an
> > >interesting topic, although I'm not too sure it's all that
> > >filesystem-related.
> >
> > Maybe not. Yet, it would be a very useful place to store data from a
> > file as a non-volatile page cache.
> >
> > Also it is something that I believe would benefit from a VFS-like API.
> > I mean there is a consistent interface a management layer like this
> > could use, yet the algorithms used to order the data and the interface
> > to the physical media may vary.  There is no single right way to do
> > the management layer, much like filesystems.
> >
> > Given the page orientation of the current VFS seems to me like there
> > might be a nice way to use it for this purpose.
> >
> > Or maybe the real experts on this stuff can tell me how wrong that is
> > and where it should go :)
>
> I don't believe anyone has implemented this before, so any experts would
> be self-appointed.
>
> Maybe this should be turned into a filesystem subject after all.  The
> complexity comes from combining XIP with writes on the same chip.  So
> solving your problem should be identical to solving the rw XIP
> filesystem problem.
>
> If there is interest in the latter, I'd offer my self-appointed
> expertise.

Right, the solution to swap problem is identical to the rw XIP
filesystem problem.    Jörn, that's why you're the self-appointed
subject matter expert!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ