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 AndreeHi! 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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST