[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 1/2] virtio: introduce `query-virtio' QMP com
From: |
Jan Dakinevich |
Subject: |
Re: [Qemu-devel] [PATCH v4 1/2] virtio: introduce `query-virtio' QMP command |
Date: |
Thu, 5 Oct 2017 19:55:44 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 10/04/2017 07:00 PM, Eric Blake wrote:
> 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).
>
But how can I declare in this notation that name "bit1" is owned by bit
#1, name "bit2" is owned by bit #2, name "bit4" is owned by bit #4, and
all other bits has no names.
> 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.
>
Yeah... I expect the following HMP output:
(qmue) info virtio
virtio-blk-device at 0000:00:07.0
status: 0x07 acknowledge,driver,driver_ok
host features: 0x0000000179000e54
guest features: 0x0000000030000e54
common features:
notify_on_empty
any_layout
indirect_desc acked
event_idx acked
version_1
specific features:
seg_max acked
blk_size acked
flush acked
topology acked
virtio-serial-device at 0000:00:08.0
status: 0x07 acknowledge,driver,driver_ok
host features: 0x0000000179000006
guest features: 0x0000000030000002
common features:
notify_on_empty
any_layout
indirect_desc acked
event_idx acked
version_1
specific features:
multiport acked
emerg_write
--
Best regards
Jan Dakinevich