Re: klibc and what's the next step?

[Olaf Hering <olaf@aepfle.de>]

On Tue, Jun 27, 2006 at 03:12:53PM +0200, Roman Zippel wrote:

> So anyone who likes to see klibc merged, because it will solve some kind 
> of problem for him, please speak up now. Without this information it's 
> hard to judge whether we're going to solve the right problems.

I do not want to see kinit merged.
It (the merge into linux-2.6.XY) doesnt solve any real problem in the long term.
Instead, make a kinit distribution. Let it install itself into an obvious
location on the development box (/usr/lib/kinit/* or whatever), remove all
code behind prepare_namespace() and put a disclaimer into the Linux 2.6.XY
releasenote stating where to grab and build a kinit binary:
make && sudo make install
It can even provide its own CONFIG_INITRAMFS_SOURCE file, so that would
be the only required change to the used .config.

The rationale is that there are essentially 2 kind of consumers:

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.
A distribution that uses a cpio archive (SuSE does that since 2.6.5 in SLES9,
and since 2.6.13 in 10.0) has no need for the kinit. mkinitrd creates a
suitable cpio archive and the contained "/init" executable does all the 
hard work (as stated in the comment in init/main.c:init())


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?

24-klibc-basic-build-infrastructure.patch forces the klibc build, even for
setups where it is not required. CONFIG_KLIBC, if it ever gets merged, should
be optional. usr/initramfs.default as example has a hard requirement.
If CONFIG_KLIBC is off, only /dev, /dev/console and /root should be part of
the cpio archive in the .init.ramfs ELF section. The exectuables come from
the cpio initrd.
I once looked briefly for a patch that would introduce something like 
CONFIG_OBSOLETE_PREPARE_NAMESPACE which will make all code behind
prepare_namespace() optional. For SuSE, this dead code just wastes build time,
and it increases the vmlinux file size. While looking for ROOT_DEV users,
it wasnt obvious to me what requirements mtd has, so I postponed that attempt.
I'm sure ROOT_DEV can go as well in your patch named
29-remove-in-kernel-root-mounting-code.patch
All can be done outside the kernel code, and there is the root= cmdline option.


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?
An external kinit for such features sounds more logical.
If there are no plans to add these features, that just means that kinit
is real static functionality-wise. So having it as external binary makes
even more sense, given the amount of build time to spent for every new kernel.

Not really related to kinit per se:
There is also not much distribution specific inside initramfs (beside the file
locations to actually create a suitable cpio archive). There is still the
boundary between "/init" and the real init on the final root filesystem.
Otherwise static kernels would not be usable on these distributions.
I'm sure a mkinitrd that works for every distribution out there is possible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/