Re: [CFT] initramfs patch

[Mike Touloumtzis <miket@bluemug.com>]

On Mon, Jul 30, 2001 at 03:50:33PM -0500, Jeff Garzik wrote:
> On Mon, 30 Jul 2001, Mike Touloumtzis wrote:
> > 
> > One thing that would make embedded systems developers very happy
> > is the ability to map a romfs or cramfs filesystem directly from
> > the kernel image, avoiding the extra copy necessitated by the cpio
> > archive.  Are there problems with this approach?
> 
> Yes -- you need to at that point store initialized structures.  Store
> the dcache in its unpacked state on the ROM image, etc.  That's the only
> way to "map" a romfs directly.  Otherwise there is ALWAYS an unpacking
> or translation step between filesystem image and in-memory image.
> 
> Mapping an in-memory image directly may seem like a good idea, but it is
> really not.  ESPECIALLY for embedded folks.

I think you're misunderstanding what I propose.  I'm talking about
having a device in /dev that would allow access to a filesystem
image (cramfs or romfs) that would be embedded in the in-memory
kernel image.

So yes, there would be an unpacking/translation step to get at the
file data, but it would be the normal memory map/page fault process
combined with the filesystem functionality already in cramfs/romfs,
and (more importantly) it would allow text pages to be dropped and
later reloaded from the kernel image, instead of duplicating data
from the kernel image into a nonpageable ramfs.  There would still
be a RAM hit but it would just be the dcache, icache, and other
such in-core metadata, not the entire contents of the files.

The reasons to integrate this into an infrastructure like the new
initramfs (instead of, say, catting the fs image onto the end of
the kernel) are:

a) The filesystem will have alignment requirements, which are
   easily specified in a linker script, and

b) We would want a block device to perform the process I describe
   above (it essentially just be a readonly ramdisk which knows
   where in the kernel image the filesystem resides, probably
   based on symbols inserted by the linker).

miket