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
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
