[OpenBIOS] General comments

[Benjamin Scott]

Hello all,

Okay, a friend of mine got me so interested in this that I had to sign
up.  And, having signed up, I of course have to put my two-bits worth
in.  It's an Internet tradition!  :) In regards to some stuff on the
OpenBIOS homepage (OB being quotes from the homepage)....

OB> Sun-like bootconsole

I think this is one of the coolest aspects of this project.  I've
always liked things like DEC's SRM console for hardware-level control. 
They give you a lot of power and control and don't get in your way.  For
our purposes, they are also simpler to program, easy to extend for new
features (just add commands and/or variables), and typically use less
memory then full-screen menus.  They also work on serial consoles.

OB> Remote administration (?)

I think I might have a better idea:  Make the BIOS data structures
available via a standard interface to the OS, allowing query and set. 
This is a good idea anyway (makes system administration easier), and
lets the OS handle all the network transport and management protocol
stuff.  I don't really see any need to have the BIOS support it
directly.  Why complicate things needlessly?  (Of course, if there is a
legitimate need for this, by all means, let's do it).

Would be nice if you could return to the BIOS UI from the OS via
function call or hardware (like the HALT switch on DEC systems).  I
suppose you might even be able to return control to the OS, if you
didn't make any intrusive changes, but I dunno if that would be useful.

OB> no Unneccessary hardware detection that makes startup slow
OB> no 16bit Code
OB> no MSDos Filesystem code

While I agree that we should dump anything that is around simply
because it was there first, let's not fall into the trap of getting so
hooked on redesigning things we forget reality.  For one, any x86 CPU
starts in real mode, so you'll need at least a 16-bit stub to init
protected mode.  Some expansion cards that provide BIOS extensions don't
work well in protected mode (older stuff, true, but Linux has always
been good on that front).  Real-mode code is sometimes simpler or
smaller then protected-mode, too.  Likewise, DOS FAT has two
advantages:  It's simple (easier to support) and nearly universal
(almost everything supports it).

I guess my main point is, we should try to avoid arbitrarily declaring
what "Must" and "Must Not" be.  Make the code design as modular as
possible, and you can include whatever you want.  Developers will
support what they know or need.  Users can choose what they want and
like.  This mirrors the design of the Linux kernel itself, and I think
it is a very good design policy to follow.

Chris Arguin ([e-mail]) posted a suggestion for a source
code tree.  If I may be so bold to make some suggestions/changes:

ui/       <- user-interface and UI extensions
  cli/    <- command-line interface
  fsm/    <- full-screen menu
  mouse/  <- mouse support (maybe?)
  gui/    <- GUI (if we get really bored :)
drivers/  <- device drivers for boot and BIOS function support
  ide/
  scsi/   <- how do we tie this in with SCSI cards that have their own
             INT13 BIOS?  write our own drivers for the SCSI chipset?
  usb/    <- can USB support boot devices?
  net/    <- network cards (for BOOTP)
init/     <- handles system initialization and the like
boot/     <- OS boot stuff (standard MBR, Linux kernel, BOOTP)
std/      <- standard BIOS call implementation (like good ole INT13)
ext/      <- OpenBIOS extensions (dunno what they are yet, tho :)
misc/     <- the ever-popular "other" category

Comments, suggestions, flames, etc?

-- Ben

---
OpenBIOS -- http://www.linkscape.net/openbios/
[e-mail]   Body: un/subscribe
Problems?  [e-mail]