Re: [klibc] klibc and what's the next step?

[Theodore Tso <tytso@mit.edu>]

On Sat, Jul 01, 2006 at 06:56:57AM -0400, Jeff Bailey wrote:
> 
> The Ubuntu initramfs doesn't use kinit, and it would be nice if we
> weren't forced to.  We do a number of things in our initramfs (like a
> userspace bootsplace) which we need done before most of the things kinit
> wants to do take place.
> 

This is going to be a problem given that people are hell-bent at
chucking functionality out of the kernel into userspace.  If various
distributions insist on having their own initramfs/initrd, we're going
to have a maintenance headache where future kernel versions won't work
on distro kernels, which is going to be painful for kernel developers
that want to stay on the bleeding edge.  We are already seeing the
beginnings of this, where the the fact that modern kernels expect the
distro initramfs will wait for the SCSI probe to finish after loading
modules and trying to mount the root filesystem has caused RHEL4
system to be incompatible with modern kernels.  

Fortunately there is a workaround by not building the MPT Fusion
device driver as a module, but if Pavel succeeds in ejecting software
suspend into userspace, and preventing suspend2 from getting merged,
*and* distro's insist on doing their own thing with initramfs, we are
going to be headed for a major trainwreck.

Personally, I would be happier with keeping things like suspend2 in
the kernel, since I don't think the hellish compatibility problems
with non-reviewed kernel functionality that has been ejected into
userspace is really worth it --- but if we *are* going to go down the
route pushing everything into userspace, it is going to be critical
that distro's buy into using a kernel initialization system which is
shipped with the kernel, and can be updated without being tied a
particular distro's non-standard "value add".  Maybe that means we
need to have hooks so that the distro's can add their non-standard
"value add" without breaking the ability for users to upgrade to newer
kernels.  But either way, we're going to have to decide which way
we're going to go, and if we're going to go down the blind
in-userspace-good-in-kernel-bad approach, the distro's are going to
have to cooperate or it's going to be a mess.

						- Ted
-
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/