Messages in this thread | | | Date | Mon, 17 Dec 2001 21:31:55 -0500 (EST) | From | Alexander Viro <> | Subject | RE: Booting a modular kernel through a multiple streams file |
| |
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.
- 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/
| |