On 02/28/13 10:37, David Woodhouse wrote:
On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote:
- Having (many!) hypervisor-specific special cases in SeaBIOS seems
wildly schizophrenic without bringing any significant benefits, compared to factoring all of that out into a codebase which *already does many of the needed things*.
It's a tradeoff. On one hand letting coreboot handle hardware initialialization would reduce the amout of code in seabios we have to maintain. On the other hand adding coreboot as middle man between qemu and seabios would add some complexity to the whole mix.
But if we do it *without* coreboot, then we get to reimplement the whole "seabios-qemu-seabios ping-pong", as Laszlo describes it, in Tianocore as *well* as SeaBIOS.
A good part of that "ping pong" is for acpi table generation. That we don't want duplicate *that* in both tianocore and seabios is pretty clear. So the question is whenever we want move acpi table generation to coreboot or to qemu?
The advantage of moving it to coreboot is that we already have some table generation infrastructure there.
The advantage of moving it to qemu is that we can easily keep acpi tables in sync with the virtual hardware. We need less communication between qemu + firmware. We gain flexibility: All firmware (seabios / tianocore / coreboot) can pick up & use the tables. That way we should get a smooth migration path from pure seabios to coreboot+seabios (or coreboot+tianocore+seabios), can switch firmware images for regression testing etc.
Using coreboot everywhere sounds good to me. Especially because on the Tianocore side we can push for Patrick's CorebootPkg to be the *primary* platform; we could even consider deprecating the qemu-specific OvmfPkg completely. And *that* in turn ensures that what everyone's working on is something that ought to be suitable for real hardware, rather than just qemu.
Makes sense, but is quite some way to go.
cheers, Gerd