Re: [OpenBIOS] OpenBIOS: reality check

[Benjamin Scott]

DK = David Kennedy 
DK> Hmm...  I certainly hope that I never get a system without an ISA
DK> bus.  I have way too many specialty cards that require it.

Well, I doubt ISA will ever go away totally, but you may see it
relegated to specialty systems.  Depending on your application, you may
find your existing ISA system suitable forever.  Or, it may be time to
move your specialty cards over to PCI.  :-)

DK> With the dozen or so PC chipsets out there, can all these differ-
KD> ent versions of the initialization code be effectively created?

This is an important point.  I don't know how things work at that low
a level.  It is entirely possible that we're biting off more then we can
chew.  On the other hand, the IBM-PC world is full of de facto
standards.  We may find much of the chipset support is the same.

DK> This one has been done over and over.  But it's done with a BIOS
DK> chip on the network card using the technique I discussed before.

I would like to have more control over the network boot process,
including specifying host and boot image at boot time.  I haven't seen
anything that does this using the ROM on a netcard, though I am far from
an expert.  Being able to "ping" from the boot monitor prompt would be a
handy tool, too.

DK> Again, because of the multitude of network boards, I forsee it
DK> being very difficult to offer this in a generic BIOS.

We don't have to support every network card ever made.  Supporting
just a few (ie, NE2000, 35x9, etc) would get us support for a large
number of systems.  And it is a universal agreement that our firmware
code should be modular, allowing the user to select which features (such
as drivers) they wish to include in the final firmware image.

DK> This  is  a rather easy extension.  But the more important one is
DK> to boot off of any controller type (SCSI, EIDE, ...)

That's a little more complex, but should be doable.  I don't think we
have to support every SCSI card on the market -- I think it should be
possible to select the interrupt services provided by disk controller
BIOSes.  I'm pretty sure that's what my BIOS does now by offering me a
"Boot SCSI or EIDE first?" option.

DK> Actually,  all BIOSs (to my knowledge anyway) have extended hard-
DK> ware diagnostics.  The problem is that nobody  knows  about  it.

Which is effectively the same as not having them.  :-)  Perhaps it
would be better to say "Extended hardware diagnostics which we can
*use*".  :-)

DK> Unfortunately,  enhanced  security is not feasable, especially if
DK> someone reaches into  the  case  and  jumpers  the  "clear  CMOS"
DK> jumper.

"It is important to realize that any lock be be picked with a big
enough hammer."  -- Sun System and Network Admin Manual

In other words, it is impossible to make a system full-proof.  But a
more intelligent password system, encrypted BIOS passwords, and the
like, would be one more step in the right direction.  :-)

DK> I  would  spend  good  money on a machine that can boot without a
DK> graphics card, and a keyboard.

Many systems can, if you set both keyboard and video to "Not Present"
in BIOS setup (or with jumpers).  But it should be possible to do a
better job.  
  Of course, some hardware may just flat-out not work without (for
example) a VGA card present, but that's bad hardware, not our fault. 
:-)

DK> and the machine has room for all of my custom ISA cards.

What exactly do all these custom ISA cards *do*?  <G>

me>   While the idea of implementing a whole new set of BIOS calls --
either
me> to be more powerful or faster, or to run in protected-mode -- sounds
me> appealing, it would be totally useless.

DK> I don't see a need to reimplement all of those calls either.  Es-
DK> pecially since most of them are kludged anyway.   Rewriting  them
DK> to  new specs (in 386 Protected mode) could get rid of code bloat
DK> in the Linux kernel, and could pave the way for some tiny  embed-
DK> ded OSs.

I think you missed me point entirely.  What I said was, reimplementing
all the BIOS calls (or creating new ones) to provide a protected-mode
interface would be pointless.  See my previous message for the reasons
why.  :-)

DK> Well, rudamentary filesystem code would be acceptible, I think.
DK> Enough to find the kernel.

That's all I'm taking about.  I don't mean full read/write/accounting
support.  Just enough to find the kernel file on disk, load it into
memory, and boot it.  Nothing more.

DK> How does other command line BIOSs do it?

Some just pass control to a secondary boot loader using a standard
interface (I'm told Suns do it this way).  Others (eg, MILO for the
Alpha) actually include Linux filesystem drivers into the firmware,
giving you the ultimate in flexability.  I'm suggestion something
in-between.  :)

-- Ben

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