On 10/04/2017 09:26 AM, Jan Dakinevich wrote:
>>>>> +{
>>>>> + 'struct': 'VirtioInfo',
>>>>> + 'data': {
>>>>> + 'feature-names': ['VirtioInfoBit'],
>>>>
>>>> Why is feature-names listed at two different nestings of the return value?
>>>>
>>>
>>> These are different feature names. First names are common and predefined
>>> for all devices. Second names are device-specific.
>>
>> If you can turn these into enums (union'd enums?) then you might
>> be able to get rid of a lot of your array filling/naming conversion
>> boilerplate. (Not sure if it's worth it, but it's worth looking).
>>
>
> I would be happy to drop this boilerplate, but how enum could help here?
> To respond my requirement it should be something like set, not enum.
> Even so, having set, I would have been needed to declare mapping between
> names in set type and bit numbers within feature bitmask.
Instead of returning a bitmask ("mask":123) as well as an array naming
those bits
([{"bit":1,"name":"bit1"},{"bit":2","name":"bit2"},{"bit":4,"name":"bit4},...]),
you could omit the bit numbers and just return an array of named bits
(["bit1", "bit2", "bit4"]). An enum lets you declare up front what
named bits are supported (and code can introspect when new named bits
are supported in newer qemu).
Perhaps it's easier to first take a step back, and show what the desired
output might be like, and then we can figure out how to represent that
output in QAPI.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
