On 04/18/18 14:03, Daniel P. Berrangé wrote:
> On Wed, Apr 18, 2018 at 01:52:19PM +0200, Laszlo Ersek wrote:
>> On 04/18/18 11:43, Paolo Bonzini wrote:
>>> On 18/04/2018 00:40, Laszlo Ersek wrote:
>>>> +#
>>>> +# Lists firmware types commonly used with QEMU virtual machines.
>>>> +#
>>>> +# @bios: The firmware was built from the SeaBIOS project.
>>>> +#
>>>> +# @slof: The firmware was built from the Slimline Open Firmware project.
>>>> +#
>>>> +# @uboot: The firmware was built from the U-Boot project.
>>>> +#
>>>> +# @uefi: The firmware was built from the edk2 (EFI Development Kit II) project.
>>>> +#
>>>> +# Since: 2.13
>>>> +##
>>>> +{ 'enum' : 'FirmwareType',
>>>> + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] }
>>>
>>> A very basic question (so not likely a suggestion for change). Why
>>> wouldn't these be features too? For example a UEFI with CSM could
>>> expose both uefi and bios, a u-boot with UEFI support could expose both
>>> uboot and uefi, etc.
>>
>> Good point. I considered "type" to be a given, from the initial
>> brainstorming, but if Dan is OK with your suggestion, I can turn these
>> into features as well.
>>
>>> Perhaps there are two dimensions, the FirmwareType tells you how to
>>> configure it and the FirmwareFeature tells you the APIs it exposes to
>>> the guest?
>>
>> I don't know enough firmware types to answer this :) I believe I agree
>> about the FirmwareFeature statement (if we also include "platform
>> requirements" there), but I have no clue about any generalizations for
>> firmware configuration.
>
> IIUC Paolo is basically suggesting
>
> {
> "description": "OVMF firmware"
> "type": "uefi",
> "features": [
> "uefi",
> "bios"
> ],
> }
>
> where 'bios' is only listed if CSM is enabled in the OVMF build. I tend
> to think that is redundant and we could just do
>
>
> {
> "description": "OVMF firmware"
> "features": [
> "uefi",
> "bios"
> ],
> }
Actually, this is how I interpreted Paolo's idea at once. I agree the
"type" member can be dropped.
>
> And declare the order of "features" list is significant. ie
>
> "features": [
> "uefi",
> "bios"
> ],
>
>
> means a UEFI firmware which has back compat for BIOS (ie OVMF with CSM)
> while
>
> "features": [
> "bios"
> "uefi",
> ],
>
> means a traditional BIOS firmware with compat for UEFI (thinking uboot
> being able to include uefi support in this case)
Is it guaranteed that lists in JSON keep the order of the elements?
Because, dictionaries definitely don't promise any ordering between the
keys.
Thanks,
Laszlo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
