On 04/10/18 11:32, Thomas Huth wrote:
On 10.04.2018 11:22, Laszlo Ersek wrote:
On 04/10/18 09:33, Thomas Huth wrote: [...]
Alternatively, what about providing some kind of "alias" or "nickname" setting here, too? So the EDK2 builds would get SystemFirmwareType="edk2" and "SystemFirmwareAlias="uefi" for example.
I hope I understand you right -- I think your suggestion ties in with my other email I just sent in this thread. So, we could tell libvirtd, "this firmware is of type 'UEFI', and you must use the 'ovmf_smm' mapping method to run it, with this file or that file as varstore template".
We could even describe the parameters for this or that mapping method structurally in the schema (in a discriminated union in QAPI JSON, or in an XSD choice element). For example, "ovmf" and "ovmf_smm" would both take "OvmfSplitFileOptions" -- a list of single varstore template files with feature enum contants attached --, while "SeaBiosOptions" would be an empty structure.
Sorry, I've got no clue about ovmf_smm and the other things you've mentioned here ;-)
I feel the key question here is whether we are allowed to directly reference a mapping method we know libvirt implements. If we are, that makes things a lot clearer (and easier, I should hope).
Key question is maybe rather: Do you want to design / implement something that is libvirt-only here, or rather something generic that could also be used for other upper layer tools that do not use libvirt? (... and looks like Daniel just had the same comment in another mail in this thread ...)
Yeah, we can't target libvirtd as the sole consumer. Laszlo