Jordan Crouse wrote:
On 11/06/08 12:37 +0200, Peter Stuge wrote:
On Tue, Jun 10, 2008 at 10:27:19PM -0700, H. Peter Anvin wrote:
APIs exist to decouple modules. Use them. I understand there is finally some serious work going on in that vein in the coreboot community; this makes sense.
The "no API" model is idiotic.
You don't feel it is possible/desirable to have all hardware code in the operating system so that boot code can be oneshot?
(of course the boot code still has to hand over state information)
What would the ideal abstraction be then?
Interestingly enough, this thread is intertwining with the "coreboot BIOSisms" threat, and Peter has gotten his wish.. "Of course, as mere producers we don't care too much, it would be interesting to discuss also with the consumers". Well, here is the owner of the init code for the only operating system we can boot. I think he qualifies as an interested party.
I don't presume to speak for hpa, but I do think I feel his concern. His areas of interest aren't so very much different then ours. With syslinux and the kernel init code, his main goal is to take a decidedly complex architecture and beat it into sanity. And for the most part, it will just work on any given x86 architecture - hpa isn't running around trying Linux on every new platform that is coming out - he trusts that the BIOS will give him the information that he needs.
Now, you can argue that that the API is old and archaic and stupid. Those are legitimate arguments, but they aren't interesting for the guy who doesn't want to have to worry about changing his code every time a BIOS software developer thinks he has something clever.
This is a problem we are already struggling with. Why doesn't gPXE work out of the box? Why wouldn't libpayload + coreinfo work on non coreboot BIOSen (by all accounts it should). The first answer is because we need to add coreboot specific code to gPXE, and the second answer is that we have _only_ coreboot specific code in libpayload. These are probably not optimal solutions.
Now, I don't know how hpa feels about the traditional BIOS API - perhaps he too would be open to a new way of doing things. But even if he is, there are lots of API consumers right behind him (ACPI, mptable, etc, etc) that would need convincing as well. Its a long road to travel, and we may never reach the end successfully. I think what Kevin is doing is exactly the right course of action - we need to play well with others, sooner rather then later and then slowly bring them along with us. That is the only way we can be successful. Storming in and saying "we are clever, support us or die!" is not a great way to win over the world.
I'll leave you with a thought - the first guy who stood up and said "Hey lets overthrow the king" got his head cut off. It takes consensus to make permanent change.
Thank you for saying this way more eloquently than I would have (I have gotten a bit hoarse over the years from yelling the same message too many times.) Your description above summarizes the issues really quite nicely.
As far as the BIOS API is concerned, it is archaic, it's ugly, it is ubiquitous, and it works. The latter two means that no matter what happens, I have to support the BIOS API. Anything coreboot does differently means more work (or that I'll simply say "forget about that stupid thing"), *especially* since there is a cost to multiple solutions for anything. As you point out, once you abandon the BIOS model you have a lot of things behind it that need changing, and largely for no good reason.
The fact that legacy BIOS runs in 16-bit mode is almost an advantage, because it has kept it from mushrooming too far out of control. It's a pretty small API and relatively well-behaved, believe it or not. Furthermore, it is quite limited, which has prevented people from abusing it too badly -- for one thing, noone expects legacy BIOS to be fast.
I would absolutely love for Coreboot to get involved as a full-fledged player on the proper BIOS stage, first of all because it would give a full-featured open source firmware solution, and second of all because it might give some leverage when it comes to driving that platform; Intel used to sort of take that role until they got obsessed with EFI.
As far as implementation is concerned - there is no law that says that the legacy BIOS needs to be written in 16-bit code. One could even trap to SMM on a BIOS interrupt and implement the actual service routines in that mode.
-hpa