Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge

[Jeff Garzik]

Miles Bader wrote:

>Jeff Garzik <[e-mail]> writes:
>  
>
>>I'm not saying that initramfs will do 
>>this out of the box :) but going from initramfs to "initromfs" should 
>>not be a huge leap...
>>    
>>
>
>Do you mean by putting the `internal' format that initramfs normally
>uses in RAM, in ROM, and skip the initial decompression step?
>
>Or do you mean have it somehow avoid copying the data areas of the cpio
>stream (i.e. store pointers from the tree-in-ram to the actual data
>blocks in ROM).
>
>I guess the latter sounds cleaner... it would also have the advantage
>that you could have a tree with the bulk of data in ROM, but which
>allowed new files to be written (which would be stored in RAM).
>  
>

Well, Linux wants file data in pages, so you would need to be able to 
get your kernel to point to page-aligned ROM regions.  Otherwise you are 
stuck with the same issues as fs/romfs or fs/cramfs or most other Linux 
filesystems -- you gotta copy the data into a RAM page before the Linux 
VFS will look at it[1].  For the initramfs cpio image itself, it can 
either piggyback inside the kernel image, or be loaded separately via 
bootloader, from ROM, or some other magic means.  Unpacking [what is 
essentially] pointers into the ROM would probably involve custom 
userland code in an initramfs which mounts and populates a ROM-based 
filesystem.

So one way or another you can have all of _your own_ data in ROM, but I 
don't want to paint too rosy a picture -- if you want to be smarter than 
fs/romfs is now, it will take some additional work.  And of course the 
ramfs-based rootfs will still be needed as the underlying writable fs.

    Jeff

[1] or you can create your own file_operations and eliminate this 
restriction... with a bunch of ROM-specific custom code that totally 
bypasses the pagecache