Ed Swierk wrote:
On Fri, Nov 7, 2008 at 7:38 AM, Jordan Crouse jordan@cosmicpenguin.net wrote:
Its getting harder and harder to make it an option. We are going to have to deal with optionROMs - regardless what any of us think about legacy software callbacks, we are not going to get very far unless we can handle legacy ROMs easily and cleanly and make them available to the payloads. Thats a fact of life. SeaBIOS is the best solution to this problem that we have so far. In my mind, that makes it mandatory.
Not every application of coreboot has to worry about legacy hardware or option ROMs.
Don't misunderstand the use of the word mandatory here. As an example, consider that optionROMs may need to be managed on any mainboard that has PCI or PCIe slots or onboard video, NICs or RAID controllers. As developers, if we cannot rule out the possibility of using an optionROM then we would need to enable that functionality. Look through the list of mainboards, and tell me how many of them fall out of this dataset? As the United States just got finished with an election, the comparison is apt - the majority will need optionROM support, and I consider that as mandatory, at least as far as any random mainboard is concerned.
To be clear, I don't object to seeing SeaBIOS in the coreboot source tree, but there must be an option to ignore it at compile time.
Absolutely, configuration options are cheap and easy - we should use them as much as possible. But I don't think anybody disagrees with this - the larger debate is if SeaBIOS should stop being an independent entity - I think the majority of mainboards says yes.
Or, look at it from the builder point of view. I don't mind having a configuration file for each mainboard - text is cheap. But if I have to build the same package for every single mainboard, at some point I start asking questions. Thats what I'm doing here.
Jordan