Messages in this thread | | | From | Dave Cinege <> | Subject | Re: Booting a modular kernel through a multiple streams file | Date | 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/
| |