ADLO committed (NO FUNCTION TABLES!)

[Eric W. Biederman]

steven james <pyro at linuxlabs.com> writes:

> Greetings,
> 
> I was thinking of locating the function table somewhere in ram. Perhaps it
> and the code itself could go in the 64 K at 0x100000 and A20 could be
> turned on to access that small highmem area with the segment register set
> at 0xffff. I hadn't considered that this would be Real mode (though I
> should have, more coffee needed!). That implys the approach of personality
> module compiled from LinuxBIOS source rather than direct dispatch into
> LinuxBIOS.

I am very very much against function tables of any sort.  It becomes
much, much to easy do something stupid.  We are talking about 10 lines of code,
it is not a problem to replicate it.

I don't have problems with possibly building from the same sources, if
they can be properly extracted.  But I would much rather be able to
build an ADLO that had drivers for multiple chipsets, detected what it
was working against (possibly with the help of the LinuxBIOS table).
And did what it needed to do all by itself.

Every firmware function call layer I have seen has had problems.  And it is
very hard to fix because it is in the firmware.

It is a given that people working on a motherboard will not have much time,
before the firmware is burnt.  So we need to keep the job of the firmware as simple
as possible.  Pieces that we can load later like ADLO can be developed after the
firmware is settled on.  And can be fixed.  The firmware is very dangerous
to touch once you have a stable configuration.

Ron is correct that firmware services evolve into OS.  EFI, the SRM,
ROM DOS, etherboot etc.  There is justification for having multiple
OS's, not all programs run on all OS's, some OS's are smaller 
and faster,  some have drivers for everything under the sun,  some
have source code, some have excellent support contracts, etc.

If I stare at the Itanium long enough (with it's PAL and SAL) I might
get convinced there is some value in some very basic minimal services
that are used all of the time. But mostly that seems to be an excuse
for not properly documenting things. 

My goal is for the LinuxBIOS table to export enough information that
things like ADLO can be motherboard independent.  In general it is
impossible to be hardware independent, but having enough information
to know which pieces of hardware you need to talk to does not sound
hard.   And as time goes there will be more boards without standard
hardware, making the work of getting ADLO running usefully harder.
This is already the case with Video, SCSI drivers.  With the current
work on serial ATA IDE drivers may soon follow suite, or at least have
several different flavors that need supporting. 

I don't even want to think about putting all of those hardware
differences behind a function call interface.    For most of those I
would rather simply not put the support into LinuxBIOS, at all.

Eric