[klibc] Query regarding initramfs

[H. Peter Anvin]

Milton Miller wrote:
> 
> 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.
> 

You could do that, sure, but you might as well call unlink(); the 
run-init utility is pretty much a drop-in replacement for pivot-root(8). 
   There are also potentially sticky issues with future kernels which 
may want to have userspace code to be run at *other* than boot time.

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

The kernel cpio unpacker is quite simple.  Even if you didn't do that 
you'd have to wrap at least a few basic items so the kernel has to turn 
them into something accessible from userspace, and at that point you 
might as well make the wrapping format cpio... classic application of 
the 0-1-infinity rule :-/

	-hpa