lkml.org 
[lkml]   [2001]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] PART1: Proposed init & module changes for 2.5
    Date
    On Sunday 23 September 2001 20:09, you wrote:
    > On Sun, 23 Sep 2001 03:12:54 -0400
    >
    > David Cinege <dcinege@psychosis.com> 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?

    Russ,

    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
    exec.

    This has already been designed and is called the Multi Boot Standard.
    You can read the spec in the GRUB source archive.
    http://www.gnu.org/software/grub/
    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
    KISS???)

    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
    Syslinux.)

    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. ftp://ftp.psychosis.com/linux/grub

    Dave
    -
    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: 2005-03-22 13:03    [W:0.025 / U:120.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site