[lkml]   [2001]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] PART1: Proposed init & module changes for 2.5
    On Sunday 23 September 2001 20:09, you wrote:
    > On Sun, 23 Sep 2001 03:12:54 -0400
    > David Cinege <> wrote:
    > > On Sunday 23 September 2001 2:37, Rusty Russell wrote:
    > >
    > > Russ,
    > >
    > > How about implementing MBS? (Bootloader module loading. IE as implmented
    > > in GRUB) so we can finally have completely modular kernels?
    > Hi Dave,
    > Why duplicate the module code in the boot loader? Surely a tiny initrd
    > or equiv is a better option here?


    No. It's much more restrictive. IMO the JOB of the boot loader is to provide
    minimal lowest level (arch dependant) device access to load and initialise
    the kernel, with enough user control to manipulate how the kernel
    is initialised. GRUB does a fantastic job of this on x86. It's the first
    bootloader I've seen 'get it right'.

    I don't suggest implementing the complete module loading in the boot loader,
    (I'm still not even sure I really like it in the kernel. ; > )
    only loading the modules themselves into memory for the kernel access during
    it's exec. (Like an initrd image is loaded) If a boot loader wants to
    understand and use modules.dep or do on the fly dependency checking, or have
    kernel userland utils to update it's conifg intelligently, that's it's
    business. I only want to see a way modules can be preloaded before kernel

    This has already been designed and is called the Multi Boot Standard.
    You can read the spec in the GRUB source archive.
    It been around a few years. It's sad only HURD(?) is using it,

    Why an initrd solution doesn't even touch on the problem:
    You have a kernel.
    It's scsi layer and scsi device drivers are all modules.

    You have a system.
    It contains a single scsi drive.
    The kernel and modules reside on that drive.

    Now the impossible exercise.
    Get that machine the boot.

    All the parts are there but you can't. Your only option is to use an initrd
    that has the required modules *merged* into it. This is just disgusting and
    silly. It's also impossible to make that initrd on that machine without a
    suplementary system. (Yes there are other ways around this by why not just

    We ALREADY have the boot loader and spec designed to allow reloading
    modules into memory this way. (GRUB) It should not be very hard to implement
    this from the pre-existing Linux intird code to read the modules out. It's
    also easy for other boot loaders to use their initrd code to implement the
    functionality. (Remember when you think about it's usefulness put it in the
    perspective of bootloaders that can read from a filesystem. IE GRUB and

    Please let's do this already...
    I look forward to one day reaching the point it's *reasonable* to have a
    completely modular kernel and that any device drivers (even boot devices) can
    be upgraded without having to update the entire kernel.

    If you've never played with GRUB yet, you can grab a nice raw floppy image
    from my ftp site.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:03    [W:0.025 / U:21.192 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site