Re: [Qemu-devel] [PATCH for-1.5] qmp: add query-drive-mirror-capabilities

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 24 Apr 2013 15:05:23 -0600
Eric Blake <eblake@redhat.com> wrote:

> On 04/24/2013 02:36 PM, Luiz Capitulino wrote:
> > The drive-mirror command was extended in QEMU v1.3.0 with two new
> 
> introduced in 1.3, extended in 1.4
> 
> > optional arguments 'granularity' and 'buf-size'. However, there's
> > no way for libvirt to query for the existence of the new arguments.
> > 
> > This commit solves this problem by adding the
> > query-drive-mirror-capabilities command, which reports the
> > existence of both arguments.
> > 
> > Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> > ---
> 
> What if we instead have a generic command querying setup, instead of
> introducing one query per command?  I'm typing this without looking at
> your patch...
> 
> { 'type': 'CommandCapability',
>   'data': { 'command': 'str',
>             'capabilities': [ 'str' ] } }
> { 'command': 'query-command-capabilities',
>   'arguments': { '*command', 'string' },
>   'returns': [ 'CommandCapability' ] }
> 
> with a sample usage:
> 
> -> { "execute": "query-command-capabilities" }
> <- { [ { "command": "drive-mirror",
>          "capabilities": [ "granularity", "buf-size" ] },
>        { "command", ... }
>      ] }
> 
> 
> Or maybe play a bit with QMP unions to make things more strongly typed:
> 
> { 'enum': 'DriveMirrorCapability',
>   'data': { 'buf-size', 'granularity' } }
> { 'union': 'CommandCapability',
>   'data': { 'drive-mirror': [ 'DriveMirrorCapability' ],
>             ...: [ ... ] } }
> { 'command': 'query-command-capabilities',
>   'arguments': { '*command', 'string' },
>   'returns': [ 'CommandCapability' ] }
> 
> with a sample usage:
> 
> -> { "execute": "query-command-capabilities" }
> <- { [ { "type": "drive-mirror",
>          "data": [ "granularity", "buf-size" ] },
>        { "type", ... }
>      ] }
> 
> And whether a '*command' argument should be optional for filtered
> output, vs. always unconditionally dumping all information on all
> commands with capabilities, vs. mandatory (can only get capabilities for
> one command at a time), all goes back to the larger question of whether
> query-* commands should allow filtering.

Not discussing filtering for now, but your proposal would superseded by
full introspection, wouldn't it?

Anyways, I also agree it's a good idea to defer this to 1.6 so we can
revisit this topic later.