[SeaBIOS] [PATCH 2/2] accept MADT over fw_cfg

[Laszlo Ersek]

On 03/21/13 13:52, David Woodhouse wrote:
> On Thu, 2013-03-21 at 13:49 +0100, Gerd Hoffmann wrote:
>>>>> How about we don't bother to determine this at runtime at all?
>>>>
>>>> Because it will be a PITA for testers + developers to figure the correct
>>>> .config switches of the day during the transition phase?
>>>
>>> Why is it a PITA?  Are you developing QEMU?  Just use the makefile from
>>> roms/config.seabios Are you using QEMU binary?  Just use the defaults.
>>
>> SeaBIOS binaries are running on a wide range of qemu versions today.
>> Changing that is a big deal.  People are not used to it, and even when
>> writing it to the README people will stumble over it.  It also is pretty
>> inconvenient in a number of cases.  For starters the usual way to
>> package seabios and qemu in distros is to have separate packages ...
> 
> I agree that for the foreseeable future, we should be able to build
> SeaBIOS such that it can cope with old versions of Qemu that *don't*
> provide ACPI tables. 
> 
> And of course we should make it cope with new versions of Qemu that
> *do*.

I'm fine with that as well.

I can't say anything about tables "in general". Regarding the MADT, we
always must have one (at least under the "APIC interrupt model", if I
remember the ACPI spec correctly), and for that this 2/2 should be OK.
The debug message regarding the table's origin I do agree with, I can
repost if that's the way to go.

Wrt. the interface. I think the current "mass dump of tables in one
fw_cfg file" is a bit inconvenient but I didn't want to change it. If we
had a separate fw_cfg *file* (not key of course) for each table, we
could define its format like:
- file not present: qemu is old, seabios should install the table,
- file is present with a special first byte: seabios should *not*
install the table,
- file is present with another first byte and a trailing blob: seabios
should install the blob as the table.

(Very coarse idea of admittedly, maybe some more headers will be necessary.)

Combining the current "big dump of tables's contents" with the more
flexible "Y/N file per table" approach seems ugly.

> 
> But I'm not sure I see any point in doing it table-by-table. Surely it
> can be all or nothing?

Not while we're implementing those "few historical commits" :)

Thanks
Laszlo