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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
