Laszlo Ersek lersek@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to OVMF
<soapbox>
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork. Maintaining a GPL fork seems just as reasonable.
</soapbox>
Regards,
Anthony Liguori
(and I never have without explicit permission), so it's been a lot of back and forth with acpidump / iasl -d in guests (massage OVMF, boot guest, check guest dmesg / lspci, dump tables, compare, repeat), brain picking colleagues, the ACPI and PIIX specs and so on. I have a page on the RH intranet dedicated to this. When something around these parts is being changed (or looks like it could be changed) in SeaBIOS, or between qemu and SeaBIOS, I always must be alert and consider reimplementing it in, or porting it with permission to, OVMF. (Most recent example: pvpanic device -- currently only in SeaBIOS.)
It worries me that if I slack off, or am busy with something else, or simply don't notice, then the gap will widen again. I appreciate learning a bunch about ACPI, and don't mind the days of work that went into some of my simple-looking ACPI patches for OVMF, but had the tables come from a common (programmatic) source, none of this would have been an issue, and I wouldn't have felt even occasionally that ACPI patches for OVMF were both duplicate work *and* futile (considering how much ahead SeaBIOS was).
I don't mind reimplementing stuff, or porting it with permission, going forward, but the sophisticated parts in SeaBIOS are a hard nut. For example I'll never be able to auto-extract offsets from generated AML and patch the AML using those offsets; the edk2 build tools (a project separate from edk2) don't support this, and it takes several months to get a thing as simple as gcc-47 build flags into edk2-buildtools.
Instead I have to write template ASL, compile it to AML, hexdump the result, verify it against the AML grammar in the ACPI spec (offsets aren't obvious, BytePrefix and friends are a joy), define & initialize a packed struct or array in OVMF, and patch the template AML using fixed field names or array subscripts. Workable, but dog slow. If the ACPI payload came from up above, we might be as well provided with a list of (canonical name, offset, size) triplets, and could perhaps blindly patch the contents. (Not unlike Michael's linker code for connecting tables into a hierarchy.)
AFAIK most recently iasl got built-in support for offset extraction (and in the process the current SeaBIOS build method was broken...), so that part might get easier in the future.
Oh well it's Friday, sorry about this rant! :) I'll happily do what I can in the current status quo, but frequently, it won't amount to much.
Thanks, Laszlo