Messages in this thread | | | Subject | Re: [Semi-OT] hot-swapping kernels | From | Matthias Andree <> | Date | 10 Jan 2000 22:34:37 +0100 |
| |
almesber@lrc.di.epfl.ch writes:
> Matthias Andree wrote: > > I think a kernel as second-stage bootloader is overkill. > > Functionality-wise, yes. Maintenance-wise, probably not. Let me explain: > the complexity of the boot process is gradually increasing over time. > One source of complexity is added functionality in the Linux kernel, e.g. > RAID. Another source of complexity are more complex setups people want to > build, e.g. see the tftp thread in linux-kernel.
As has been laid out, people can use initrds for this.
> Mirroring major new kernel functionality in a boot loader tends to be a > time-consuming business and always contains the risk of version drift. > Also, if a feature is missing in the boot loader, it will be hard to > add by users who need it.
I am aware of the maintenance issue. This is however a design flaw.
I have seen some i386 OSs, NetBSD 1.4.1, OpenBSD 2.6, Linux 2.0/2.2, DOS6.22/Win95B, WinNT4, Solaris 2.6 -- each have a different boot sequence to get the kernel into RAM and kick it into boot.
While I don't expect to circumvent chainloaders for commercial OS's (and I don't really care), if there was a carefully chosen sequence that *BSD and Linux shared, that would constitute quite a gain.
> On the other hand, a Linux kernel is implicitly capable of handling > everything one might successfully throw at a Linux kernel. Somebody > who is able to make use of a given feature in a "regular" system > should also find it quite feasible to make use of it from the second > stage. In particular, normally, no modification of the boot loader > will be necessary.
Yes. Still, you need "old-fashioned" simple boot-loaders, be they filesystem-aware (GRUB, SYSLINUX), be they not (LILO), be they TFTP based or whatever, to get the second stage bootloader into RAM, whatever its name and origin. No matter if it's called GRUB or LINUX, you cannot simply boot that kernel from a SoftRAID, you cannot currently boot from reiserfs either.
> Of course, using a little Linux system as a second stage loader may > appear excessive. One issue can be space. On most regular PCs, there > is sufficient storage space nowadays to afford this overhead. There > will always be exceptions where space is highly critical (e.g. > embedded, diskless, etc.) so the current, more streamlined boot > process needs to continue to work.
I'd appreciate if the standard bootstrapping sequence was less size-sensitive like it is now. LILO is extremely fragile, the kernel itself must not exceed a certain size in order to boot. These are limitations today.
Even a simple stripped-down linux kernel that can do nothing more than bring buses, SCSI/IDE and filesystems in will have some 50 kB which means you already need what GRUB calls a stage1.5 loader.
> Another issue can be time. That's why I think it will be necessary > that the first kernel can pass the results of bus scans etc. directly > to the second kernel. The latter can then skip this process, or > possibly initiate a new scan in the background (e.g. if the second > kernel may be able to see more devices), while already proceeding > with the information passed from the other kernel.
Since the internal presentation of data varies over kernel versions, you will most certainly impose further restrictions on the boot sequence such as "2nd stage must be compiled along with the kernel" - exactly the opposite of your aim. If you bring data into a generic format, you will need additional layers in the kernel -> code bloat. That's ot what you want either.
The biggest delays on my machine come from the BIOS boot sequences, not from the kernel itself booting. So, it's not the time issue for me.
> > I think people should rather work merging the advantages of LILO and > > those of GRUB, to get a DECENT bootloader. > > Don't forget all the non-i386 architectures. Also, there are several > specialized boot loaders on i386 alone (e.g. SYSLINUX), which may have > to track some changes too.
So the solution is a stable, universal booting sequence with a defined API. I haven't looked deeper into the "multiboot standard" that comes with GRUB. Having a carefully-designed booting interface will probably get us rid of the bootloader maintenance issue.
As for other architectures: I have used SILO on a Sparc32, which is file system aware just like GRUB is. This is a big advantage since it essentially keeps your machine booting even if you play around with kernels and forget about /sbin/lilo which happens every now and then.
-- Matthias Andree
Hi! I'm the infamous .signature virus! Copy me into your ~/.signature to help me spread!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |