RE: Booting a modular kernel through a multiple streams file

[Grover, Andrew]

> From: Alexander Viro [mailto:[e-mail]]
> On Mon, 17 Dec 2001, Grover, Andrew wrote:
> all they have to do is 
> get the modules in
> > memory and indicate via the multiboot struct where they are.
> 
> *shrug*  Your "all they have to do" is quite heavy.

GRUB 0.90 does this today. All other bootloaders could also do it quite
easily, since this is just an extension of what they have to do for the
kernel and initrd images.

> I've had a very dubious pleasure of dealing with our boot 
> sequence lately.
> Adding more cruft to it (including in-kernel linker, for fsck sake) is
> _not_ a good idea.

I see this as cruft elimination. By adding a kernel linker (which can be
discarded after init) it allows one to increase the modularity of the kernel
- without using an initrd. Heck, you could make the initrd code
modularizable ;-)

> Folks, whatever had happened with "if it can be done in 
> userland - don't
> put it into the kernel"?

Yes, but this isn't an absolute rule. IIRC that rule also has an "unless it
makes things a lot simpler" clause, too.

> That goes for a _lot_ of code.  Mounting root.  Detecting the type of
> initrd contents.  Loading ramdisk from floppies.  Asking to press
> key (you really ought to look what is done for _that_).  Speaking
> DHCP - we have a kernel DHCP client, of all things.  All that stuff
> can (and should) be done from userland process.  And there's much
> more of the same kind.

> There is a word for that and that word is "crap".

These examples are either a direct result of initrd complexities, or not
related.

Initrd exists to allow a two-phase startup. My point is that why have a 2
phase startup when you can have a 1 phase startup? Also, I'm not advocating
ditching the initrd capability, but wouldn't bootloading modules be
preferable for the majority of the systems currently using initrd out of
necessity?

Regards -- Andy