[klibc] initramfs scripts + cpio archive stuff

[H. Peter Anvin]

Russell King wrote:
> 
> Issues that need to be addressed at some point:
> 
> 1. how do we get kernel command line parameters into initramfs?
> 
>    my favoured option is to remove the ones we care about from
>    the kernel, they will then appear in the environment for the
>    init script
> 

That's certainly an option (and will handle the stuff we remove from the 
kernel nicely.)  There is always /proc/cmdline, of course; however, 
going forward we may want to consider if the kernel command line really 
is going to be enough (255 characters maximum.)

> 2. load_ramdisk currently does not perform any detection of gzip vs
>    romfs vs ext2 vs minix.  If this feature is required, we may have
>    to look at file(1).  I've already looked at file(1) around klibc
>    0.17 time, and it wasn't anywhere clean enough for klibc.

Looking for major numbers hardly needs file(1).  A small set of 
hardcoded majors is just a matter of reading the beginning into a buffer 
and looking for the magic numbers in known locations.

> 3. do we need to worry about initrd support?
> 
>    initrd has this nasty habbit of wanting to change the root device
>    that should be mounted by poking a device number into some random
>    /proc/sys file (yuck).  Obviously this isn't going to be portable
>    to initramfs.  I'd argue that initrd support is obsolete with
>    initramfs in the kernel.

I agree; it's fundamentally braindamaged, and has been obsolete for 
quite a while even so; the currently favoured method of initrd uses 
pivot_root().

> 4. running other scripts so initramfs can be extended easily by
>    concatenating images.
> 
>    my idea here is to do something like:
> 	 for script in /addon/*; do $script; done
>    so we run any scripts found in /addon which other cpio archives
>    can add at unpack time.

How about calling it /rc.d/ instead :)

But yes, I like that idea.

For what it's worth, I actually got shared-but-not-dynamic klibc to work 
today (on i386; it requires some crt0.S changes although they are 
relatively minor -- rather than expanding the feature set of crt0.S I 
have now convinced myself that once you have a pointer and the stack is 
set up the rest of the work can be done generically, so I've moved it to 
C.)  It saved about 2-3K per binary, which was less than I'd expected; 
less than I would have expected, although it certainly makes blowing 4K 
on supporting real error messages a heck of a lot more defensible.

klibc itself, once stripped, is currently 23956 bytes in size, so it's 
only a win if we expect to have a dozen or more binaries on the typical 
initramfs...

Since klibc is shared but not dynamic, I have it set up to automatically 
generate a hash from the symbol addresses, and makes that part of the 
interpreter name.  You can only run against the exact same version of 
klibc as you compiled a binary against.

I'm not really sure if the dynamic klibc is actually worthwhile.  At 
least we have the technology now...

	-hpa