Sure ... but that's not what I meant. Linux interacts with the BIOS in
the following ways:
1) boot loading
2) retrieval of system parameters for later use by the kernel (e.g.
VGA, SMP EBDA, ...)
3) services provided to the running system (e.g. APM)
With my proposed extension, 1) stays roughly the same, to load the
"second stage" kernel. The good news is of course that all the
restrictions that apply to 1) (e.g. the dreaded 1024 cylinder limit
or subtle EDD restrictions which kick in once you overcome the limit)
no longer affect the entire boot process.
For all further kernels (until the next reboot), a Linux kernel
performs the duties of 1). Most of the information in 2) is
overwritten by the running kernel, so we need to preserve that,
because the next kernel(s) need that information too. Finally, 3) is
there anyway, so no special treatment is needed for that.
Adapting 2) is really where the bulk of the work is.
> I have considered that as well. Unfortunately, it seems like just as
> big a project.
A few years ago, a friend implemented something like this on Amiga-SVR4
within a few days, so it doesn't seem to be all that bad, even if you
take into account that Linux probably has a much wider interface to the
BIOS than SVR4 had to whatever low-level environment the Amiga had.
- 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/