lkml.org 
[lkml]   [2006]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2006-07-02 00:07    [W:4.152 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site