Use of BIOS calls in modern code (Was: Re: [OpenBIOS] 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         P.Lister at sychron.com    PGP (RSA): 0xE4D85541
Sychron Ltd          http://www.sychron.com  PGP (DSS): 0xBC1D7258
1 Cambridge Terrace  Voice: +44 1865 200211
Oxford OX1 1UR  UK   FAX:   +44 1865 249666

-
To Unsubscribe: send mail to majordomo at freiburg.linux.de
with "unsubscribe openbios" in the body of the message