On Wed, 3 Feb 1999, Dave wrote:
What should the purpose of the BIOS be?
In my mind, the BIOS should be a minimal piece of code, used only to initialize the hardware to the extent needed to boot the system. This would include initializing the memory space and boot device, reading the first block of code from the boot device and turning control over to that block of code. This "boot block" would then finish initializing the hardware, loading API's, OS's or whatever, from the boot device.
Well, I think that's true. It's one way of giving the BIOS a new purpose.
That means, we have (for now) two general ways:
a) (my suggestion) Implement a new BIOS with a new API. b) (your suggestion) Implement a new BIOS with only the functions to access a "larger BIOS", say, a kernel or other on any media.
Of course, (a) needs more space and probably is slower than (b). (b) has the advantage to only do the absolute minimum of jobs to access the kernel. But that kernel (maybe a pre-kernel) also has to initialize the hardware, it has to know exactly on which board it resides etc.. (a) would partly (main parts) hide hardware details from the next-to-load kernel, so except for the new interface and a new kernel loader, the OS (and the kernel) doesn't have to change very much.
Any further thoughts? We need a direction, and this is a main crossing, I think! Folks, your opinion, please!
The idea of the BIOS providing an API is something that developed in the early days of PC's when each card had its own BIOS/API supplied in ROM on the card. IBM and the clone makers quickly tried to consolidate these separate BIOS blocks into a single EPROM. The problem with this solution is that the BIOS is not flexible, it is very hardware dependent, is optimized for a single OS and is very complex.
Exactly that is, what the above solution (a) is thought for, added to the flexible idea of burn-time configuration (i.e. a "make config"). This solution would demonstrate it's principle flexibility at "make config" level, but the BIOS itself would not have to be complex, redundant, with large unused pieces of code.
A simple BIOS, whos only task is to initialize the CPU/Memory/Boot Device, then load and execute a boot block (from the boot device) would be preferable to trying to replicate the "BIOS as an API" model that is used in todays PC's.
Well, that's exactly the topic to talk about!
The problem is: Then your BIOS would have, say, in the simplest way some 10k of code (binary), without using encryption, authentication, network etc.. And all the complexity is in the boot block, which, of course, has no limit except on the available RAM.
The problem is, that then _both_ BIOS and boot block would have to match each other and the motherboard. To keep them in sync can not be done in a general way - think of someone who swaps harddisks etc.
Of course, if it gets too large what we want the BIOS32 to be in the (a) way, we've got a problem, and I think, we will have this problem somedays. Of course, then something like your idea would be good - maybe on a per-module basis? - just a thought.
I think that the "BIOS as a boot loader" model is simple and flexible enough that it will be easy to maintain (especially in a free software environment) and easier to evolve as the hardware and software environments change. All of the intelligence (system initialization and API's) reside within the code stored on the boot block (rather than in the BIOS code stored in EPROM/EEPROM).
What's your suggestion concerning remote boot (network, USB, firewire, ...)? how would _that_ match your idea?
Using this approach you would not have to worry about optimizing the BIOS code for any specific OS. The BIOS's only job would be to load/execute the first block from the boot device and then get out of the way.
hmmm, I mean, the partitioning scheme should be kept for a minimum amount of compatibility to other OSes. Either the boot loader resides on an own partition (like the OS/2 boot loader) or it would be loaded like DOS - implicitly from the partition (boot block, file name searching, loading, executing). The problem is: Both need an API to continue loading or to search for data on the media (harddisk, etc.). I don't think that it would fit into something like a boot sector ("first block from the boot device"). What exactly do you mean with "one block"?
Winschdawos, - Matthias