Re: [RFC] Advanced XIP File System

Am Tuesday 02 May 2006 23:53 schrieb Jared Hulbert:
I will be submitting a new filesystem for inclusion into the kernel as
soon as it is ready.  (It mounts but doesn't like doing much else
right now.)  I would like to get feedback now to mold the development
as we go along.  Please comment on the technical approaches and other
inherent qualities or lack thereof.  Let me know of any serious
obstacles to inclusion in the mainline.  We will Lindent it and clean
it up quite a bit before really submitting.

You may find it at its very boring sourceforge site
https://sourceforge.net/projects/axfs/.  Browse the source at
http://svn.sourceforge.net/axfs
Or get the tarball at
http://prdownloads.sourceforge.net/axfs/axfs-0.1.tar.gz?download


What is it?:
- AXFS for Advanced XIP File System.
- Intended to be a root filesystem for embedded systems
- Readonly
- Uses addressable memory such as NOR flash instead of a block device
- Borrows much from CRAMFS with Linear XIP patches
- Allows XIP* of individual pages instead of just individual files
- Uses filemap_xip.c where possible

* By XIP, eXecute In Place, we mean that when a file is mmap'd() the
pages are mapped directly to where they are stored in non volatile
storage, rather than copied to RAM in the page cache and mapped from
there

Nice, this is the first time I heard of anyone using filemap_xip on MTD.

Why a new filesystem?
- XIP of kernel is mainline, but not XIP of applications.  This
enables application XIP

ext2fs does have XIP of applications, but of course only works on
block devices, not MTD. Is there more missing than an implementation
of block_device_operations::direct_access for mtd_blktrans_ops?

Why can't you get the same result with a combination of cramfs for
data files and ext2 with -o xip for your mmapped binaries?

- Cramfs linear XIP patches not suitable for submission and lack some
features of AXFS

Is that a fundamental problem of cramfs, or rather a problem of the
implementation of the linear XIP patches for it? IOW, can't you just
do a better patch to add filemap_xip support to cramfs?

- Design allows for tighter packing of data and higher performance
than XIP cramfs

why? by how much?

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
    ... lines that cramfs has in total. ... to the XIP changes, which I want on block devices anyway. ... So if we did fork cramfs I would submit a simple patch to cramfs for ... filesystem, cramfs-linear. ...
    (Linux-Kernel)
  • Re: What File System supports Application XIP
    ... > I know that Cramfs has supported Application XIP. ... Obvisously cramfs can not support XIP, ... Ramdisks are simply RAM ... block devices that behave like any other block device. ...
    (Linux-Kernel)
  • Re: ¡@[*©U§£¶l¥ó*] Re: What File System supports Application XIP
    ... Cramfs seems to support it now. ... Subject: ¡@Re: What File System supports Application XIP ... Ramdisks are simply RAM ...
    (Linux-Kernel)
  • Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
    ... Please don't add this xip support to cramfs, ... use something like the existing ext2 xip mode instead of add support ... Look at the xip extensions for ext2 for example, they don't bloat the filesystem too much. ...
    (Linux-Kernel)
  • Re: Osirix for windows?
    ... for sharing data and applications among cancer researchers. ... XIP has been developed to run in a plug-in architecture for DICOM ... imaging applications, but requires an application architecture that is ... independent application) using the XIP development environment. ...
    (comp.protocols.dicom)