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 ...)
Thomas