DC = Dave Cinege <dcinege@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@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@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 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 <hawk@ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
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 <viro@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 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 -- Sucks95 users are extremely stubborn - each time when M$ tech support advices them to install an OS they install you-know-what... --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
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. -- http://www.psychosis.com/emc/ Elite MicroComputers 908-541-4214 http://www.psychosis.com/linux-router/ Linux Router Project "The only way to remain cutting edge, is to design for things that do not yet exist." -- Me : ) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
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/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
participants (3)
-
Alexander Viro -
Benjamin Scott -
Dave Cinege