Re: Booting a modular kernel through a multiple streams file

Dave Cinege (dcinege@psychosis.com)
Sat, 22 Dec 2001 19:28:18 -0500


On Monday 17 December 2001 21:31, Alexander Viro wrote:

> *shrug* Your "all they have to do" is quite heavy.

Lilo (broken), syslinux (not very difficult), GRUB, (already implemented).
The list is not long. It's little differeent then a boot loader supporting
initrd loading.

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

Yes the guilty are well known...

> Adding more cruft to it (including in-kernel linker, for fsck sake) is
> _not_ a good idea.

Which is why all of that shit that loads multiple initrd floppies, etc,
etc should be gutting and replaced with a solid initrd system that
can load tar.gz's to tmpfs. Jeez...I happen to have such a patch RIGHT
HERE....for 3 years now. (minix prior to tmpfs existance...)

Loading initrd and boot time kernel modules, from multiple sources,
belongs in 'pre-kernel' (prom/bootloader) land. Most importantly this
boot loader is already implemented for IA32.

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

Already done (properly) in GRUB. Userland (after the kernel boots) is
no place for this. It's too late to be done cleanly. I agree the kernel
is no place either.

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

This is a very much a failed concept. In theory it sounds nice. My
experience in
1) implementing a Linux OS from scratch
2) administering multiple networks of mission critical servers
says this doesn't work well.

Dave

-- 
The time is now 22:54 (Totalitarian)  -  http://www.ccops.org/
-
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/