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@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@freiburg.linux.de with "unsubscribe openbios" in the body of the message