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