[OpenBIOS] BIOS extensions are pointless (was: More comments...)

[Benjamin Scott]

WA = William A. Arbaugh <waa at dsl.cis.upenn.edu>
WA> Not true actually, Linux does use some bios32 functions for PCI
WA> support.  My guess is that they'll still need some BIOS level
support
WA> for PnP, Power management, and not to mention DPMI etc.

  You're right of course.  I had forgotten about the PnP stuff
entirely.  I'm not sure how DPMI works, but it's a fair bet it needs
BIOS support, too.

  I think it might be better to say that re-implementing things like
INT13 in protected-mode would be pointless.  The few things that modern
OSes actually do *use* the BIOS for are definate canidates for
improvement and possible protected-mode reimplementation.  However,
"BIOS32" implies it may be protected-mode already.  Anyone know more
about this?

DW = David Woodhouse <Dave at imladris.demon.co.uk>
CA = Chris Arguin <Chris.Arguin at unh.edu>
DW> Regarding the module support:
DW> We can either link them at flash time, or have the BIOS search
through
DW> the available modules when it boots. I prefer the latter,

  While I do agree in theory, memory space limitations may force us to
link the BIOS together before programming the flash.  Which isn't really
a big deal.

DW>> Other than that, I don't see any point in extra protected-mode
DW>> functionality - as you rightly say, anything running in protected
mode
DW>> is going to have its own drivers already.
CA> Not to be too purest... but is that the "Right Way"? The BIOS is
CA> *supposed* to abstract that away. It doesn't. Maybe it should...

  Originally, yes, the IBM-PC BIOS was a hardware abstraction layer. 
Rather then, say, having disk device drivers, you called INT13 and got
support that way.  Now, the original IBM-PC platform has been extended
so much about the only thing *left* is the original BIOS service code,
like INT13.

  One might argue we should "fix" that, that we should put all that
hardware abstraction back in.  Other platforms (the Mac comes to mind)
accomplish this very well.  A standard hardware abstraction API has
obvious advantages.  However, it is typcially accomplished by providing
a low-level API in firmware to which devices talk to.  Each device
implements the support for this API.  Due to the open nature of the
IBM-PC platform, this is obviously not going to happen.

  The only other way to do it would be to write device drivers for each
and every device on the system, incorporate them into firmware, and let
the OS call our new hardware abstraction API.  Besides the fact that
this would be totally redundent, I don't know that we have the flash ROM
space to accomplish this.

  Even more important, I don't think it *would* be the Right Thing to
do.  The IBM-PC mindset has become such that device abstraction occurs
at the OS level.  This allows greater flexability and faster
development, something that has kept the IBM-PC line going where others
have failed.  Software is easier to change then firmware.  I don't
really think that we should try to go back to the "old way" of doing
things, despite the advantages.  If you really want hardware abstraction
in firmware, buy a Mac.  <grin>

CA> On a related note, I just bought a 8 Gig SCSI disk.
CA> Due to limitations of my SCSI controller,
[snip]
CA> I now have an 8GB Linux Disk. That is not a bad thing, but it wasn't
CA> what I was intending. So there is another bug for us to fix :)

  I don't know that we can.  Geometry translation for SCSI would be
handled by your SCSI controller and its BIOS, not the motherboard BIOS
(which would only control EIDE gemometry translation).

  Actually, to the list in general: Does anyone know exactly *where and
how* geometry translation occurs?  I've been thinking it must occur in
the motherboard BIOS for onboard EIDE controllers.  But we already know
many OSes bypass the BIOS.  I was assuming they were still talking to
the EIDE controller through the BIOS, just via a different route.  Is
that correct?  Or is geometry translation implemented in the EIDE
controller chipset itself?  Or something else?

						-- Ben <hawk at ttlc.net>


---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request at linkscape.net   Body: un/subscribe
Problems?  dcinege at psychosis.com