On Wed, 24 Apr 2013 15:05:23 -0600
Eric Blake <ebl...@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 <lcapitul...@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.
