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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
