Subject: Re: klibc and what's the next step?
Date: Tuesday 11th July 2006 13:45:54 UTC (over 10 years ago)
On Tue, Jul 11, 2006 at 06:48:34AM +0200, Olaf Hering wrote: > One is the kind that builds static kernels and uses no initrd of any kind. > For those people, the code and interfaces behind prepare_namespace() has > not changed in a long time. > They will install that kinit binary once and it will continue to work with > kernels from 2.6.6 and later, when "/init" support was merged. Or rather > from 2.6.1x when CONFIG_INITRAMFS_SOURCE was introduced. > > The other group is the one that uses some sort of initrd (loop mount or cpio), > created with tools from their distribution. > Again, they should install that kinit binary as well because kinit emulates > the loop mount handling of /initrd.image. This is for older distributions > that still create a loop mounted initrd. Kinit SHOULD be merged into the kernel, and the responsibility of creating the initrd/initramfs image should be moved from the distribution into the kernel build process. There can and should be a way for distro's to add their own "value add specials" into the initrd/initramfs image, but we have to take over creating the base initial userspace environment. It's not just uswsusp (still not convinced it's a good idea, but if we're going to do it we have to wrest control of the initramfs away from the distro's), but finding and mounting iSCSI disks, LVM setup, etc. > In earlier mails you stated that having kinit/klibc in the kernel sources > would make it easier to keep up with interface changes. > What interface changes did you have in mind, and can you name any relevant > interface changes that were made after 2.6.0 which would break an external > kinit? When you load a SCSI driver (the one that bit me was the MPT Fusion driver), it no longer waits for SCSI bus probe to finish before returning. So the RHEL4 initrd fails to find the root filesystem, and bombs out. This change was definitely made after 2.6.0, and is an example of the sort of change which wouldn't have happened if kinit was under the kernel sources and not supplied by the distro. > As others have stated in this thread, the code behind prepare_namespace() is > very simple. It doesnt know anything abould lvm etc, nor about mount by > filesystem UUID/LABEL nor does it know how to deal with properly with new > technologies like iSCSI, evms, persistant storage device names, usb-storage, > sbp2 or async device probing. > Should all that knowledge end up in the kernel source on day? Some of this will probably need to be farmed out into files provided by external packages, but I **hope** that they are true upstream external packages, and not distro-specific specials, which is one of the reasons why the current initrd/initramfs situation is so.... unsatisfactory. Clearly some kernel-mandated interface for other packages to insert scripts and binaries during the early-boot process would be a good thing; but the core initramfs functionality should IMHO belong to the kernel. - Ted