steven james firstname.lastname@example.org writes:
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.