On Wed, 25 Feb 1998, Odd Skjaeveland wrote:
A quick scan of historical postings makes me think the group would benefit from clearing up a few things.
True enough. We've argued out quite a few ideas, and on some of them the dust may have settled without any clear understanding of what we should do.
There seems to be a demand for having certain functions in ROM. File system code has been mentioned, and also a boot loader of some kind to get rid of LILO.
The only reason, AFAIK, to have any filesystem code is to do the bootloader that replaces LILO. The two go together.
Making the BIOS be more than a BIOS would be a mistake in my opinion. The BIOS is sopposed to be the hardware abstraction layer, and I think it should be kept that way.
I posted something like this before, and I agree with you to some extent. The BIOS is a bit more, however. The BIOS, despite its name, is a low-level hardware configuration, initialization, testing, and abstraction layer.
Assuming we shadowed the BIOS (no big deal) and wrote all the hardware abstraction in protected mode, then OSes like Linux could use BIOS calls without any of the delay currently associated with BIOS calls. I think that this is the "Right Way"
But no matter what, Linux will still have all the old drivers. Sure, we can hack the kernel to have a "OpenBios" support, which will expect the drivers to be in BIOS, but there will be plenty of people who will still need the older drivers, so the Linux source will still have to have them. Win95 won't be fixed in any hurry, unless Microsoft makes their own BIOS. So even if it is the "Right Way", there may be no benefit from doing it.
If we need a better BIOS, then we should build one. I think a discussion on BIOS topics and how we could improve it, would do us good. Please don't confuse it with where the BIOS is stored. Pulling a new BIOS from disk after startup from a primitive ROM based BIOS, is ok. If the code is a hardware abstraction layer, it is still a BIOS.
This is true. But what if my harddrive crashes. Tradionally I could still boot off of floppy. If critical sections of my BIOS were on that disk, I would have to have a floppy with that BIOS code. It just starts to get a little ugly.
I've argued that it could be done by keeping "extentions" on the disk, so that the BIOS would just lose some features in the event of a harddrive crash (and probably features you wouldn't use when doing emergency repair work to the computer).
If we would like to move code normally kept on disk to ROM, like putting file system code or a LILO-killer in ROM, then let us do so. But let us not make it part of the hardware abstraction layer code.
We've all agreed that the code should very modular. The BIOS currently contains a very simple loader, and some of us just want to... fancy it up a bit :)
So what are the goals? Putting file system code, a LILO-killer, networking software or other code in ROM because it is better than pulling it from disk? Or is it to build a better hardware abstraction layer? Or both?
Not just because it is better than pulling it from disk. If your machine goes down, and it is headless, and the problem is, for example, the seconday cache is bad, how do you fix it? You drive over to where the machine is, connect up a monitor and keyboard, reboot the machine, enter BIOS setup, and disable the cache. If the BIOS can work over the network, all those steps go away.
If I may suggest a utility that I think belongs in ROM rather than on disk: an improved memory test. Note, I did not say I think it should be part of the BIOS code, just that it should reside in ROM.
I think that one of the modules that a lot of people will want is a more extensive bootup test, or maybe a secondary, optional, intensive test.
(ROM is, by the way, a pretty hopeless acronym because a read only memory is totally useless. Even PROM doesn't make any sense, how can one program a read only memory? If we'd known better back in the stone age, we would have called it a WORMM, write once read many memory, or something...)
For the benefit of further discussions, I suggest we somehow make it clear wether we are talking about putting non-BIOS type of code in ROM or if we are talking about actual BIOS code.
Just like ROM is a bad choice of words, these days BIOS is also a bad choice. BIOSes do a lot more than Basic Input/Output. They always have done more, and now they do a lot more (and with modren OSes they don't do much relating to their name).
-- Chris Arguin | "...All we had were Zeros and Ones -- And Chris.Arguin@unh.edu | sometimes we didn't even have Ones." +--------------+ - Dilbert, by Scott Adams http://leonardo.sr.unh.edu/arguin/home.html |
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com