Well, considering that the main role of the BIOS is usually to get in
the way, I see this as a feature ;-) What needs to be done is to
isolate information obtained from the BIOS such that it can be passed
on to the next kernel. Right now, this information is scattered a bit
all over the place (e.g. VGA, disk, SMP).
Things get trickier for linux->non_linux transitions. I'm not sure if
that part is really feasible (in the sense of "can be made to work in
almost every case", not "will work most of the time with selected
versions of this or that OS on selected hardware").
> Catch-22?
Think of that first kernel as a second stage of the boot loader. The
first stage only needs to be able to boot that specific kernel, using
whatever mechanism gets that done.
Now you have a fully functional kernel that can do things like RAID5
restoration, read weird file systems, access the 8th drive on the
3rd IDE extension card, load a kernel over NFS, etc.
The disadvantage is of course that this second stage kernel has to
have the drivers to access all this. This is mainly an integration
issue (1,2), and probably less severe than it sounds - people who are
making fundamental changes to their system structure (e.g. migrate
to LVM or RAID) will have to do something non-trivial about the boot
process anyway.
(1) Just like initrd - most Linux users would have a hard time setting
up a valid initrd from scratch, but that doesn't prevent
distributors from making good use of it. And nowadays there are
also scripts helping users to set up initrd.
(2) Okay, I admit that a BIOS disk driver would be helpful as a
backup.
The main problem I'm trying to address is code replication. The more
capabilities get added to the boot process, the more code has to
exist in the kernel/system and in the boot loader. The only reliable
way I can see to automate the process of moving code from the Linux
kernel/system to the boot loader is to use a Linux kernel as the boot
loader.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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/