Philosophical question...

[Matthias Wächter]

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

-- 
Der Wein mit der Pille ist in dem Becher mit dem Fächer.
-----------------------------------------------------------------------------