Re: [PATCH] PART1: Proposed init & module changes for 2.5

David Cinege (dcinege@psychosis.com)
Sun, 23 Sep 2001 23:57:24 -0400


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/