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]

[Alexander Viro]

On Sun, 1 Mar 1998, Benjamin Scott wrote:

<snip>
> 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.  :-)

Less than 128, BTW.
> 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.

Let me summarize my objections against FAT.
a) 8+3 limit. Single dot limit. (I.e. no names like kernel-2.0.33)
b) Extremely fragile (lists are much more fragile than trees)
c) EXTREMELY FRAGILE just because DOS (shrug) or Sucks95 (BARF!) can
access it.
d) Nontrivial loaders (other than get the first sector of some partition
and let it run) are needed only for Linux and *BSD. On these systems we
can add a new filesystem.
e) If you managed to hose read-only mounted filesystem in Linux/*BSD it
means that you hosed all your disk. It is not an easy job, believe me.
Then you'll have to boot from floppy anyway. I keep Linux boot floppies
around, but DOS? What for? And if you don't have Linux/*BSD you don't need
filesystem with kernels at all, so for UNIX-free machines it's non-issue.

Conclusion: hell with FAT. If we need a filesystem let's implement a
good one. It's not that hard.
    							Al

[Dave Cinege]

Alexander Viro wrote:
> c) EXTREMELY FRAGILE just because DOS (shrug) or Sucks95 (BARF!) can
> access it.

This is fixed by an optional unique patition ID, *IF* you want the boot code to
remain on a seperate partition.

My peace:
Everything reads FAT, most things read ext2. We need (and already have) code
for both.

[Alexander Viro]

On Sun, 1 Mar 1998, Dave Cinege wrote:

<snip>
> My peace:
> Everything reads FAT, most things read ext2. We need (and already have) code
> for both.

Dave, it just occured to me that we can have the damned thing (FAT, ext2,
whatever) written on the very same Forth. Think a bit - it will not make
the execution slower. But it will give us helluva lot of flexibility.
All we need is the function that reads sector #n from device foo.
Evrything above is _pretty_ simple exercise. What will you say about it?

I.e. we have 
    a) a lot of low-level stuff - C & assembler.
    b) Forth interpreter - C & assembler.
    c) hardware testing etc. written on that Forth using a)
    d) menu system - ditto.
    e) crash-dump saver - ditto.
    f) boot-time debugger - ditto.
    g) loader/FS - ditto.
    h) Good 'ol BIOS (realmode, etc.).
Core == a+b+c
Minimal system == a+b+c+g.
Minimal DOS system == a+b+c+h
Usual system == a+b+c+d+g+h
Plus extras for the screwy situations.

What do you think about such priorities/scheme?
    							Al

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