[OpenBIOS] Filesystem code in BIOS

[Benjamin Scott]

DC = Dave Cinege 
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 
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 
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
universal.

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

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