Use of BIOS calls in modern code (Was: Re: [OpenBIOS] Why protected mode?)

[Timothy J. Massey]

On Fri, 16 Jul 1999 14:54:01 +0200 (CEST), Matthias W�chter wrote:
> Currently we have the same BIOS interface as the 8086 (except
> for the INT16 Bios extensions which are not used by some OSes, sadly,
> Linux too in opposition to NT and Win98).

Linux can't really take advantage of *any* BIOS routines (OK, outside of the
loader and such), even when Win98 can.  The reason is simple:  Linux is
cross-platform.  Alphas don't have the same BIOS as PC's, which don't have
the same BIOS as Macs which don't have the same BIOS as a Sun.  So how could
Linux use a BIOS routine that isn't commonly available.

Now, there is a way that Linux could make use of BIOS calls (if they really
wanted to) without losing cross-platform objectives:  let the C compiler
libraries use BIOS calls.  But there, you run into the same problem.  The C
compiler used for Linux (GCC) is cross-platform, too.  So, they don't want
to use the BIOS, either!

In any kind of portable OS, any feature that isn't available on all systems
is a liability.  It's something that will either increase the difficulty of
porting the code to a system that doesn't support some feature, or requires
additional effort to add that functionality to a particular port.

Basically, the BIOS in a modern computer is a hardware configurator and boot
loader.  Personally, I think that that's fine.  I'm not looking for a BIOS
to do anything more.

Tim Massey

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Use of BIOS calls in modern code (Was: Re: Why protected mode?)

[Niklas Ekström]

On Fri, 16 Jul 1999, Timothy J. Massey wrote:
> Linux can't really take advantage of *any* BIOS routines (OK, outside of the
> loader and such), even when Win98 can.  The reason is simple:  Linux is
> cross-platform.  Alphas don't have the same BIOS as PC's, which don't have
> the same BIOS as Macs which don't have the same BIOS as a Sun.  So how could
> Linux use a BIOS routine that isn't commonly available.

Ofcourse Linux have architecture specific code also.
> In any kind of portable OS, any feature that isn't available on all systems
> is a liability.  It's something that will either increase the difficulty of
> porting the code to a system that doesn't support some feature, or requires
> additional effort to add that functionality to a particular port.
> From what I've heard about OS design, the trend seems to be that when

implementing the OS you are not supposed to aim for crossportability, but
for the highest possible performance on the individual platforms. What
_should_ be portable is the programming interfaces that should be common
on all supported platforms.
> Basically, the BIOS in a modern computer is a hardware configurator and boot
> loader.

I don't know what computer systems you have in mind, but at the ones I'm
thinking of (Sun, Apple etc) the BIOS is much more than that (see
OpenFirmware which is basically a Hardware Abstraction Layer).
> Personally, I think that that's fine.  I'm not looking for a BIOS
> to do anything more.

I could live with that too, but it seems very unnecessary. Consider this:

When you make the BIOS you (probably) wish to make it able to boot from
as many devices as possible (Floppy, Harddisk, CD, Network, USB...), so
then you have to include software for supporting these devices
(devicedrivers) into the BIOS.

And since you already got the drivers in the BIOS, many would feel that it
would be a complete waste not to make these available to the OS through a
BIOS Runtime Interface (BRI).

Besides, there are many major advantages of having the drivers available
through a BRI. For instance the OS doesn't have to support a million 
different chipsets (Intel, AMD, etc) and motherboards. A very small and
flexible OS could be made. Also, the OS developers could concentrate on
making cool OS features instead of writing drivers to support hardware.

/ Niklas

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Use of BIOS calls in modern code (Was: Re: Why protected mode?)

[Edward Brotsman Dreger]

> Basically, the BIOS in a modern computer is a hardware configurator and
> boot loader.  Personally, I think that that's fine.  I'm not looking for
> a BIOS to do anything more.

Agreed.

In fact, if memory serves me (me who is too lazy at the moment to grep),
there is somewhere in the Linux kernel source that proclaims something
like, "BIOS? We don't need no stinkin' BIOS!"

Though modern BIOSes *can* perform IRQ, I/O, and DMA steering, even this
is oft disabled for all but the peripherals needed to boot via "PnP
Operating System Installed".

On a side note...  Today I was intrigued by a customer's system.  I don't
know the motherboard model, and I hath not the BIOS string at hand, but
let me go from memory:

- AcerAcros
- 430FX/PCI/ISA
- 486 Socket3

Via the BIOS, one could not only manually steer PCI IRQs (with display of
IRQA, IRQB, IRQC, and IRQD) and DMA channels, but this is the only BIOS I
can recall seeing that allowed manual *I/O port* reservation.

Back to an earlier thread: What development model are we following?

IMHO, I think that the "BIOS" proper should be the bare minimum.  All
other functionality, even some "standard" BIOS functions such as ACPI, 
could be implemented as modules -- even as option ROMs.  Since we'll need
option ROM loader code, anyway, why not reuse it for the "roll-your-own"
modules?

Eddy

*-----------------------------_/~~_/----------------------------------*
  Edward Brotsman Dreger                 "Your Success is Our Success    
  Network & Systems Manager            Our Expertise is Your Advantage"  
  Brian's Consulting Services /~__/~\   www.brics.com * 316-794-8922    
_________________________________________________________________________
SPAMbot bait:  abuse@localhost  postmaster@localhost  [e-mail]

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Use of BIOS calls in modern code (Was: Re: Why protected mode?)

[Peter Lister]

On Sat, 17 Jul 1999, Edward Brotsman Dreger wrote:
> Back to an earlier thread: What development model are we following?
>
> IMHO, I think that the "BIOS" proper should be the bare minimum.  All
> other functionality, even some "standard" BIOS functions such as ACPI, 
> could be implemented as modules -- even as option ROMs.  Since we'll need
> option ROM loader code, anyway, why not reuse it for the "roll-your-own"
> modules?

If I may delurk to support this view (and repeat some stuff that I put on
the wishlist).

My interest in openbios is that Sychron is working on cluster software to
make cabinets full of commodity motherboards into clusters (think in terms
of an SP2 or SGI Origin at 10% of the cost). Buying commodity hardware is
easy; OS software exists - make up a Beowulf from the Extreme Linux CD, or
(better yet) buy the stuff we're working on. BUT the available commercial 
BIOSes thwart easy installation and management (and hence scaling up).
Until a proper minimal bios is available we have to equip each one with 
a graphics card, have a console switch, etc.

Beowulfs, and the kind of cluster we have planned will use 100 or 1000s of
bios chips per system - so serious production quantities for ROM blowing
are very achieveable (Intel themselves are talking about filling buildings
with Ks of motherboards for the ASP market). I know very little about
BIOSs, processors and motherboards, so much of the list traffic is chinese
to me, but I've been used to the monitor ROMs of e.g. Digital and Sun
systems over the past 10 years. Though they weren't exactly perfect, and 
started to bloat, I feel that I've lost the degree of control over my 
hardware that I had back then, so I am very encouraged by opinions
expressed here that a minimal bios chip with *optional* extras is the way
to go - if this means that we can...

- Eliminate the bulky and unneccesary stuff e.g. GUIs
- Control motherboards and monitor status at the BIOS level via e.g.
  serial line or USB, so a command line is essential, not merely useful.
- Configure hardware to do *exactly* what we need.
- Easily add our own bios functionality, if that seems useful, without
  needing to touch the rest of the BIOS, just like a Linux kernel module.
- Do the above on 1024 nodes en masse. :-)

The less functions that are blown into ROM, the happier I am, cos that
means they can be pulled from the net (or USB or whatever device seems
appropriate) as required.

openbios can really make a mark in the compute / server cluster market -
Phoenix / AMI and friends have the desktops sewn up, so I really would
urge the openbios development model towards minimalism in the first
instance and cluster support in the second. I don't wish to deprive anyone
of GUIs or other bells and whistles, I just require them to be optional.
There may be bells and whistle that we'd like, such as APM support for our
UPS of choice, or a heartbeat between systems to provide fast non OS 
reliant notification of hardware failure, which are irrelevant for desktop
PCs, and I have no wish to impose them on anyone. I don't want to watch
advertisements as my desktop PC boots, and certainly not when restarting
a cluster node.

If anyone else is interested in issues relating to BIOSs for servers,
especially for large clusters, please get in touch, on or off this list.

Peter Lister         [e-mail]    PGP (RSA): 0xE4D85541
Sychron Ltd          http://www.sychron.com  PGP (DSS): 0xBC1D7258
1 Cambridge Terrace  Voice: [phone]
Oxford OX1 1UR  UK   FAX:   [phone]

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message