[klibc] Query regarding initramfs

[Milton Miller]

On Apr 4, 2005, at 6:00 PM, H. Peter Anvin wrote:

> Milton Miller wrote:
>> With the current code there is no reason initramfs pieces have to
>> be linked into the kernel.   Instead the pieces can be loaded into
>> memory by the bootloader and passed to the kernel as an initrd.  As
>> of early January, the pieces can have empty (zeroed) space between
>> them.  The linking mentioned above is a historical reference.
> >
>
> Well, you *can* link it into the kernel; in fact, the initramfs can 
> come from *both* sources!

I didn't mean to imply otherwise.

> This is a good thing; it's not currently used that much, but will soon.

I see the split as an opportunity for application optimization.

>> ...  It is a ramfs, not tmpfs that could fall out into swap.
>> Each symlink takes a page.  It can't be unmounted to free space,
>> instead the files must be removed.  ...
>
> Note that it's a pretty trivial patch to the kernel to change rootfs 
> to a tmpfs instead of a ramfs.  In fact, the main reason that hasn't 
> been mainstreamed is because "noone has asked for it."

I did notice that when rootfs went in. *  (I wasn't asking for it).

Another change that could be made is to expand the cpios into a
mounted file system rather than into rootfs, which would eliminate
one of the differences vs. initrd and would allow pivot_root to work.

I have also observed that init/initramfs, like prepare_namespace, is
all user space code.   Getting the initial user space program does
become a bit of chicken and egg.  I have played with putting a
executable linked into the kernel as /init (the first time was
before the initramfs cpio spec was published).   While it could give
flexibility in how many pieces are expanded and when (e.g. leave data
compressed, uncompress into a mounted file system), I haven't
found a reason to actually propose any of these yet.  The userspace 
variant tends to have a bit more space overhead, although it could
provide more space and code re-use.  The last round provided a
method to avoid copying pages, instead installing them directly into
the page cache.  And of course these approaches allow the data
format to be application dependent.

milton

* (Actually I remember some people complaining that CONFIG_RAMFS
became fixed as yes, and the argument made was that it was so
little additional code with the libfs and simple_ routines that
it didn't matter.  Granted that was a space argument vs this one
being a functionality argument.)