Initramfs status [LWN.net]

One bit of unfinished 2.5 business is "initramfs," the boot-time root filesystem which is tacked onto the kernel binary image. The plan is to move much of the initialization-time code out of the kernel and into initramfs; the result should be a smaller kernel and a safer, more flexible boot process.

The code to support initramfs has been in the kernel for some time. The big missing piece has been on the user space side. Before anything useful can be run in user mode as part of the boot process, there must be a whole environment to build it in. Attaching the C library to the kernel image is not an option that would appeal to many, so a special-purpose C library is needed. That library is "klibc," which has been under development by Greg Kroah-Hartman and others for some time. klibc provides a minimal set of standard functions, written with an eye toward portability and small size.

Greg recently posted an update on klibc. The library seems to be essentially complete, at least until somebody tries to do something requiring functions which have not been provided. The sticking point, at the moment, seems to be a bug in the initramfs unpacking code. Greg is interested in input from anybody who would like to help debug that problem. Once that's been ironed out, it is mostly just a matter of figuring out which boot-time operations should be taken out of the kernel and moved into a user-space implementation. If that is going to happen in 2.5, it would be nice if it happened soon; making major changes to the boot process brings with it a real risk of destabilizing the kernel for a while.

(Log in to post comments)

Initramfs status

Posted Feb 6, 2003 3:48 UTC (Thu) by gregkh (subscriber, #8) [Link]

Just to set the record straight, I did not write the current version of
klibc. That work was done by Peter Anvin, and others. I had originally
written a first cut at klibc, but that was under the GPL, and it was
determined that a BSD style license would be better. Peter then started
from scratch and created a very small and complete library, and took the
klibc name (which was fine with me). I am merely trying to add klibc to
the kernel build process.

why not GPL?

Posted Feb 6, 2003 18:57 UTC (Thu) by pflugstad (subscriber, #224) [Link]

What issues does the GPL run into here?

Also, is this a "shared" (i.e. .so), so multiple boot programs get
one copy, or is it your standard library (.a)? The former would
almost seem to be a requirement from a size point of view.

Thanks,
Pete

Re: why not GPL?

Posted Feb 7, 2003 6:16 UTC (Fri) by larryr (guest, #4030) [Link]

> is this a "shared" (i.e. .so)

I think it is in effect a shared object, but there is some magic to do it.

> What issues does the GPL run into here?

I think only GPL-compatible programs can link with GPL libraries, and
that is too restrictive for the klibc requirements.

Larry