Yep, and some of them are pointers to the actual data. Plus there is
the potentially large EBDA used by SMP systems. But in principle, all
this is simple work.
> However, this doesn't guarantee that the new kernel isn't going to choke
> on the hardware configuration, which is going to be radically different
> than a machine that has been booted from reset.
This is certainly something that needs to be looked into. Fortunately,
most drivers seem to be fairly conservative by what they expect and do
a thorough reset first. What may cause more problems are things like
IRQ autodetection. Also, LOADLIN is empirical evidence that drivers
are indeed usually quite robust with respect to the initial device
state.
> Hence, it is not so much the BIOS interface that's the problem, but the
> fact that Linux really likes to break the BIOS, and break it pretty
> hard.
Yes, I'm afraid that we can't depend on much of the BIOS to be
available, although the "second stage" kernel is in a slightly better
position for preserving a valid BIOS context than a "production"
kernel, because it only needs to access a subset of the hardware (e.g.
no SMP, no frame grabber, etc.)
While this is of course inconvenient, it's not a show-stopper. After
all, at installation time, we need to be able to build a kernel that
supports all those devices already. In fact, if using LILO, we're
already successfully running such a kernel.
So the main problems with not having access to the BIOS are
1) "second stage" kernel needs to be updated more frequently, i.e.
whenever substantial hardware changes occur (unless it has
already access to a suitable driver, of course)
2) extending the mechanism to boot an arbitrary other OS is
probably not feasible
1) just makes an existing dependency a bit more explicit. 2) is a
pity, but isn't any worse than what we have today.
- 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/