linux-kernel - Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

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]

Date:	Thu, 7 Jun 2007 20:37:07 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	Jared Hulbert <jaredeh@...il.com>
Cc:	Christoph Hellwig <hch@...radead.org>, carsteno@...ibm.com,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	richard.griffiths@...driver.com,
	Richard Griffiths <res07ml0@...izon.net>,
	Linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

On Wed, Jun 06, 2007 at 11:26:38AM -0700, Jared Hulbert wrote:
> >FYI: Cartsten had an xip fs for s390 aswell, and that evolved into
> >the filemap.c bits after a lot of rework an quite a few round of
> >review.
> 
> Right.  So now we leverage this filemap_xip.c in cramfs.  Why is this a 
> problem?

Using filemap_xip.c is of course good.  Hacking cramfs up to contain
totally different codepathes is not.

> >> What??  You mean like use xip_file_mmap() and implement
> >> get_xip_page()?  Did you read my latest patch?
> >
> >Yes.  This is the highlevel way to go, just please don't hack it into
> >cramfs.
> 
> Right, so this latest patch _does_ implement get_xip_page() and
> xip_file_mmap().  Why not hack it into cramfs?

cramfs used to be a block based filesystem.  You hack in support to
work directly on physical addresses.  Your create a lot of different
codepathes that are only used for one of the usecases.

Instead of just talking here I've hacked up a small demo on how this
should be approached.  I've taken cramfs with your modification and
remove all the support for block devices.  In addition we now could
rip out the mutex serializing all reads and clean up the way xip
support is hooked in.  The result is a slightly smaller and cleaner
filesystem that even more important doesn't require pulling in
the whole block layer which is especially important for embedded
devices at the lower end of the scala.  This is just a proof of
concept and thus is still named cramfs, no docs or copyrights etc
are updated.  It's still incomplete aswell because we'd probably
want a better selection of files to use xip for, and we'd need
a real API to talk to the lowlevel driver for xip instead of the
physical address hack.  I still think it'd be even better to just
hook xip support into jffs or logfs because they give you a full
featured flash filesystem for all needs without the complexity
of strictly partitioning between xip-capable and write parts
of your storage.

The code is at http://verein.lst.de/~hch/cramfs-xip.tar.gz.
-
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/