qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]