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/