Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 09 Aug 1999 10:41:02 -0700 | From | "H. Peter Anvin" <> | Subject | Re: Kernels > 1M |
| |
Werner Almesberger wrote: > > H. Peter Anvin wrote: > > I think the kernel is largely by definition too late, in particular > > because one of the first things the Linux kernel does is to burn all the > > bridges to the BIOS. > > 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). >
No, that's not really true. The BIOS is still necessary (like it or not) -- it's the only way to access devices (disks, mainly) until actual device drivers can be loaded. It is not just a matter of information -- it's a matter of CODE.
> 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.
I have considered that as well. Unfortunately, it seems like just as big a project.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
- 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/
| ![\](/images/icornerr.gif) |