Messages in this thread | | | Date | Sat, 1 Jul 2006 11:05:07 -0400 | From | Theodore Tso <> | Subject | Re: [klibc] klibc and what's the next step? |
| |
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/
| |