RE: Booting a modular kernel through a multiple streams file

Alexander Viro
2001-12-18T02:32:16Z

On Mon, 17 Dec 2001, Grover, Andrew wrote:

>
> OK so (correct me if I'm wrong) there are two parts to loading modules -
> getting them in memory, and then resolving references. My understanding of
> Christian's work is that the bootloader (e.g. GRUB) gets them in memory, but
> then it is up to the kernel linker to resolve refs. So yes, there would be
> an additional piece of code (marked __init), but it would not have to be
> duplicated for each bootloader -- 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.

> I don't think this will obsolete any existing boot methods, but it seems
> like an additional genuinely useful capability for the Linux kernel to have.

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.

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

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

Let loader leave an archive to be unpacked into rootfs? Sure. Let kernel
exec /init on rootfs and leave the rest to it? Absolutely. But let's
stop adding userland stuff into the kernel. Loading modules _can_ be
done from userland - insmod does it just fine. And that's where it should
be done.