[OpenBIOS] Filesystem code in BIOS

Benjamin Scott hawk at ttlc.net
Sun Mar 1 00:18:14 CET 1998

DC = Dave Cinege <dcinege at psychosis.com>
DC> The BIOS **MUST** be able to at least read one common FS or this
DC> projects usfulness has been cut down 10,000%!

  I don't know about "must".  Personally, I would find basic read-only
FS support very useful in the BIOS, both for booting the kernel as well
as for doing firmware updates direct from floppy.  But many people, for
some reason I quite honestly don't understand, seem to regard this as
taboo.  So it should be kept optional.  :-)

GW = Greg Weeks <greg at durendal.ml.org>
GW> OS specific code does NOT belong in the BIOS.

  Why not?

  I'm serious.  You have to have OS specific code *somewhere*. 
Otherwise you can't boot your OS.  These days, the BIOS exists mainly to
initialize the system hardware and load the bootstrap.  The bootstrap
then loads your OS.  We routinely fiddle with the bootstrap for one
reason or another; why not just move it into flash ROM?  It seems
pointless to require passing control from one block of boot code to
another just because one block resides in firmware and the other on
disk.  Having it all in ROM makes more sense to me.

GW> With something like openprom in SUNs et. al. with romable forth it
GW> becomes possible to write extensions in forth that are portable and
GW> ROMed.

  Why are people making a big deal over the term "BIOS" vs "ROM" or
"firmware"?  Does it really matter?  :-)

GW> I haven`t decided if the extensions should be in ROM (128K isn't
GW> very much)

  With efficient code and data compression, 128K goes a long way. 
Remember, UNIX used to run on systems with 128K total main memory.  I
would hope we would be able to implement a glorified bootloader in that
space.  :-)

GW> P.S. can we change the list to have a reply-to header that points
GW> back to the list?

  I second this.

AV = Alexander Viro <viro at math.psu.edu>
AV> Why? What kind of filesystem should it understand? FAT??? Damn,
AV> I'ld prefer not to have the stinker around at all.

  FAT has two key advantages: It is very simple, and it is nearly
universal.  The first helps us keep our code size down and minimizes the
possability of bugs.  The second is useful in emergency situations.  I
don't think I've met a microcomputer OS yet that didn't have some way to
support FAT (either built-in or with add-on software).  That can be very
handy if you need a kernel in a hurry and the only other networked
machine around is a Mac or some such thing.  :-)

  FAT actually bears a strong resemblence to the "stand" filesystems
some UNIXes use to boot.  Such filesystems are typcially limited in
filename length, have no security, and are flat (no directories).  FAT
isn't ideal for this, but suits the purpose, and like I said, is nearly

  I'm not saying we should and I'm not saying we shouldn't, I just
wanted to point this out for further contemplation.  :-)

					-- Ben <hawk at ttlc.net>

OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request at linkscape.net   Body: un/subscribe
Problems?  dcinege at psychosis.com

More information about the openbios mailing list