Use of BIOS calls in modern code (Was: Re: [OpenBIOS] Why protected mode?)
ebrinker at gne.net
Sun Aug 1 22:54:03 CEST 1999
I agree. I do very much agree. A bios built of a minimal ROM based loader
and loadable modules would allow the OpenBIOS to support almost any
imaginable configuration (even Wintel if you wanted).
At 08:05 PM 7/21/99 +0100, you wrote:
>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"
>If I may delurk to support this view (and repeat some stuff that I put on
>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
To unsubscribe: send mail to majordomo at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
More information about the openbios