[klibc] Query regarding initramfs
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.
More information about the klibc