Re: [RFC 1/5] qmp: add QMP command query-virtio

[Eric Blake]

On 4/2/20 5:02 AM, Laurent Vivier wrote:
> This new command lists all the instances of VirtIODevice with
> their path and virtio type
>
> Signed-off-by: Laurent Vivier <address@hidden>
> ---

> +++ b/qapi/virtio.json
> @@ -0,0 +1,54 @@
> +##
> +# = Virtio devices
> +##
> +
> +##
> +# @VirtioInfo:
> +#
> +# Information about a given VirtIODevice
> +#
> +# @type: VirtIO device type.
> +#
> +# @path: VirtIO device canonical path.

One order here,

> +#
> +# Since: 5.1
> +#
> +##
> +{ 'struct': 'VirtioInfo',
> +  'data': {
> +    'path': 'str',
> +    'type': 'str'

and another here.  I don't think our doc generator cares, but it is nice 
to document things in the same order they are declared.

Why are we using open-coded 'type':'str' instead of an enum type? 
Aren't there only a finite number of virtio types, in which case an enum 
is a better representation (not to mention making it introspectible when 
we add a new virtio type)?

> +  }
> +}
> +
> +##
> +# @query-virtio:
> +#
> +# Return the list of all VirtIO devices
> +#
> +# Returns: list of @VirtioInfo
> +#
> +# Since: 5.1
> +#
> +# Example:
> +#
> +# -> { "execute": "query-virtio" }
> +# <- { "return": [
> +#        {
> +#            "path": "/machine/peripheral-anon/device[3]/virtio-backend",
> +#            "type": "virtio-net"
> +#        },
> +#        {
> +#            "path": "/machine/peripheral-anon/device[1]/virtio-backend",
> +#            "type": "virtio-serial"
> +#        },
> +#        {
> +#            "path": "/machine/peripheral-anon/device[0]/virtio-backend",
> +#            "type": "virtio-blk"
> +#        }
> +#      ]

The resulting QMP will still be the same with an enum type (as the 
on-the-wire format is still the string name of the enum constant), but 
using an enum will have knock-on effects to the C code; it may be better 
to convert to an enum in one patch, then add the query-virtio command in 
a second.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org