[klibc] Query regarding initramfs

Milton Miller miltonm at bga.com
Tue Apr 5 01:11:16 PDT 2005


On Apr 5, 2005, at 2:44 AM, H. Peter Anvin wrote:

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

Well, s/pivot_root/mount -t bind/ or s//mount -t move/ or whatever
your choice is.  Point is unmount would free the space.

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

I'm well aware of that.  I'm pointing out we traded that code for
a user-space in kernel cpio unpacker.  Not to say there aren't
benefits to the change.  I haven't seen klibc or other non-kernel
code to unpack an initramfs yet.

And while I understand its easier to merge patches that remove
prepare_namespace with klibc and sample programs in the kernel
tree, I'm not totally convinced that is the best longterm choice.

milton



More information about the klibc mailing list