Jordan Justen jljusten@gmail.com writes:
On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori anthony@codemonkey.ws wrote:
"Michael S. Tsirkin" mst@redhat.com writes:
On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote:
I don't think it's a good idea to move BIOS functionality in QEMU.
Just to clarify: generating ACPI tables is not BIOS functionality. It ended up in seabios for historical reasons.
A normal scenario for ACPI tables is that they are written in ASL and compiled with IASL.
I wouldn't call this the normal scenario. Some tables are static but more tables are dynamic than you'd think. If you're a firmware engineer and you have to support dozens of platforms, it's much easier to make the tables dynamic than attempt to maintain dozens of ASL descriptions.
Anthony is right. Firmware for "real" systems contains the tables as binary aml output from the asl compiler, but also goes through extensive hoops to tweak the ACPI information.
On the other hand, "real firmware" doesn't have the luxury of being able to just download the ACPI tables like fw-cfg might be able to offer.
I'm a little concerned that firmware might find a desire to still customize the tables, and thus the fw-cfg solution might be too restricting. It does seem to work out okay for other VMM projects though. (It does seem to be working for Xen in OVMF. But, I'm not certain how well it is working, since I don't have a Xen setup.)
I mentioned in the other thread that perhaps QEMU could also consider making the ACPI code available under some 'appropriate' license, which would allow firmware writers to leverage the code directly if desired. Perhaps a dual/multi license situation for the relevant files?
Would the OVMF developers participate in a GPL version of OVMF that live outside of the EDK2 tree?
I think the only solution to the licensing problem is a GPL-friendly UEFI build...
Regards,
Anthony Liguori
But, if the fw-cfg route works, then it seems the easiest option for firmware writers.
-Jordan
On Mon, Jun 3, 2013 at 4:12 PM, Anthony Liguori anthony@codemonkey.ws wrote:
Jordan Justen jljusten@gmail.com writes:
I mentioned in the other thread that perhaps QEMU could also consider making the ACPI code available under some 'appropriate' license, which would allow firmware writers to leverage the code directly if desired. Perhaps a dual/multi license situation for the relevant files?
Would the OVMF developers participate in a GPL version of OVMF that live outside of the EDK2 tree?
I think the only solution to the licensing problem is a GPL-friendly UEFI build...
Sounds like there is no chance for a multi-license scenario then? My idea here was that QEMU could consider what potential licensing situations alternative firmware writers might desire, and attempt to multi-license the code so it could be used as reference code for those potential consumers.
I guess if that is not possible and the fw-cfg method doesn't work out, then we'll probably need to keep doing our best in re-implementing the ASL/ACPI code.
OVMF is an important part of the EDK II project, and thus a viable OVMF within the EDK II tree is important. Therefore, we need BSD licensed code for the core pieces of OVMF. (Such as producing ACPI tables.)
You mentioned that FatBinPkg in the EDK II tree is a particular issue for some OVMF derivatives. To solve that (as I mentioned in the other thread) I'd be willing to publish a git-submodule version of OVMF. This would also allow OVMF derived projects to include other packages. (Potentially with different source licenses.)
Given that there are no FAT driver alternatives, the only purpose I could see for this anytime soon would be something that incorporates the seabios-csm.
-Jordan
-
Anthony Liguori -
Jordan Justen