[klibc] Query regarding initramfs

[H. Peter Anvin]

Milton Miller wrote:

> 
> 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.

Eliminating pivot_root() is a good thing.  It seemed like a good idea at 
the time (heck, it was my idea), but it really has a bunch of ugly 
corner cases.

> 
> 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.
> 

Uhm... you know that this is what the whole klibc project is all about, 
right?  There is a directory in the klibc tarball called "kinit" which 
is exactly this; in particular when it's done it will replace all the 
prepare_namespace() code in the kernel.

	-hpa