As a newbie on the list I allow my self a couple of critical remarks and a few possible stupid questions.
A quick scan of historical postings makes me think the group would benefit from clearing up a few things.
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.
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.
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.
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.
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?
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.
(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.
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
CA = Chris Arguin chris.arguin@unh.edu CA> Assuming we shadowed the BIOS (no big deal) and wrote all the hardware CA> abstraction in protected mode, then OSes like Linux could use BIOS calls CA> without any of the delay currently associated with BIOS calls. I think CA> that this is the "Right Way"
The "Right Way" is most definately *not* to have device-drivers in the motherboard firmware. If you are going to do this at all, you should have a hardware abstraction API in the motherboard firmware. That API would be the common ground between the OS and the hardware. You wouldn't need kernel-level device drivers at all.
Obviously this is never going to happen on the PC, but let's assume it could.
Problem #1: To update the device driver, you have to update the firmware for the device. So every device has to either (1) have flash ROM or (2) be a pain-in-the-ass to upgrade. Neither solution appeals to me.
Problem #2: Every time a new technogy comes out, you lack a hardware-level API. You have a mess even worse then DOS. At least with DOS, you could patch and hack the OS and/or interrupt table to get by. I don't even want to think about every OEM patching and hacking at my firmware! :-)
As for us writting our own device drivers and putting them in the BIOS, I really want to know: Why? :-)
CA> This is true. But what if my harddrive crashes.
What if your flash ROM melts? :-) I'm just pointing out that you can always create a situation that prvents you from booting. That is one reason why system admin types have jobs. <g>
CA> Tradionally I could still boot off of floppy. If critical sections of my BIOS CA> were on that disk, I would have to have a floppy with that BIOS code. It just CA> starts to get a little ugly.
I do agree. Compaq puts part of their BIOS setup interface on the system hard disk shipped with the system in some of their PCs. Needless to say, things can get very ugly if you don't have that around. We could have a situation like some early Sun systems, where if the system disk crashed, you had to ship the entire system back to Sun for repair. :-)
(Disclaimer: I've never had to do that, but I've been told about it. I may have been told wrong.)
I've argued that it could be done by keeping "extentions" on the disk,
One man's extension is the next lifeform's critical function. :-)
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.
I'll drink to that! Well, actually, I'll drink to anything, but it's still a good idea. <grin>
-- Ben hawk@ttlc.net
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
-
Benjamin Scott -
Chris Arguin -
oskjaeve＠sivos.rl.no