Re: [Qemu-devel] [PATCH v4 04/10] block: make 'top' argument to block-commit optional

[Jeff Cody <jcody@redhat.com>]

On Wed, Jun 04, 2014 at 02:59:44PM -0600, Eric Blake wrote:
> On 06/04/2014 07:51 AM, Jeff Cody wrote:
> > Now that active layer block-commit is supported, the 'top' argument
> > no longer needs to be mandatory.
> > 
> > Change it to optional, with the default being the active layer in the
> > device chain.
> > 
> > Reviewed-by: Eric Blake <eblake@redhat.com>
> > Reviewed-by: Benoit Canet <benoit@irqsave.net>
> > Signed-off-by: Jeff Cody <jcody@redhat.com>
> > ---
> 
> Unrelated to my review, but I wish we had done a better job at making
> the qemu 2.0 addition of active commit introspectible.  Had we made
> _this_ patch at the same time, introspection would be possible by
> creating a dummy blockdev, then attempting a block-commit that omits the
> 'top' argument (since the error message for a missing required argument
> [old qemu] is different than the message for a blockdev that can't be
> committed [new qemu]).  But since this change is in a different release
> than where we supported active commit, I'm stuck coming up with some
> reliable way to do a probe of whether active commit is supported so that
> libvirt knows whether to expose active commit on to the end user.
>

Well, I think what we _really_ need is true QAPI introspection.

Unfortunately, libvirt can't rely on the QEMU version to determine API
levels. This leaves it needing to do various QAPI contortions to
figure out what is supported and what is not supported, which seems
clunky and probably not sustainable long-term.

But I agree with the gist of what you saying, I think: libvirt and
QEMU should make sure to stay in the loop with each other on
command discoverability.

With that said, 2.1 soft freeze is not that far off; what other QAPI
commands might we be saying this about once 2.1 is out?


-Jeff