On Mon, Feb 25, 2008 at 07:29:15PM -0500, Kevin O'Connor wrote:
If by "table" you mean code the answer is that coreboot does not like callbacks by design.
Well, it wouldn't be coreboot that got the callbacks, it would be that binary blob at 0xf0000.
..
Seriously though, I don't think implementing the real-mode irq handlers is that technically challenging
No, certainly not. However, I think that coreboot being legacy-free is a very important, if not the most important, feature.
Yes, there is a transition period where some systems need a legacy layer in order to start up, but I really want that to be distinct from coreboot.
So, I'd look at it as coreboot initializing and loading another "table" at a certain area of memory.
I draw the line at code (hence my dislike for ACPI and VSA) and had this in fact been nothing but a table I would not mind, but since it is code I think it should never be closer to coreboot than being a payload.
Some OSs will make use of it - others wont. I don't see a lot of down sides to deploying it.
It would always be present, regardless of whether an OS does make use of it or not. It would waste resources and be generally unclean. Worst-case it would cause conflicts or confusion.
The big upside is that, with the proper handlers, all modern OSes will load out of the box. This will be a big selling point to hardware vendors - especially those that want to deploy a single solution for both mass-market and niche markets.
I consider the BIOS interface to be useless for new systems and I don't want to further expanded BIOS use in any way.
Your point is crystal clear, and I completely agree that at present there simply must be a way to get these legacy interfaces.
I certainly appreciate you reviving ADLO and your effort with bochs-bios, but I do not want it included and always-on.
//Peter