[libvirt] [PATCHv9 1/9] blockjob: add qemu capabilities related to block jobs

[Jiri Denemark]

On Tue, Oct 23, 2012 at 14:16:22 -0600, Eric Blake wrote:
> On 10/23/2012 01:52 PM, Peter Krempa wrote:
> > On 10/23/12 04:10, Eric Blake wrote:
> > I know that it's convenient to have this in the upstream release as it
> > would remove the need to backport that feature every time. Said this, I
> > still don't like the idea dragging this stuff into the upstream code as
> > upstream would be responsible for supporting that from the time it went in.
> > 
> > I am willing to give in on this if somebody else thinks that it would be
> > beneficial, but right now I'm not convinced that we want this upstream.
> 
> I suppose it's not too hard to split this into two patches - one for
> upstream that uses only drive-mirror (and provides but not populates the
> feature "drive-reopen",), and one for backporting to RHEL but omitting
> from upstream that checks the __com.redhat_* commands.  We'll see if any
> one else has a strong opinion one way or the other
> 
> For precedence, note that we HAVE pulled other changes upstream for
> supporting RHEL 6.3 and CentOS qemu out-of-the-box with upstream
> libvirt, such as our change to recognize that if 'qemu-kvm -help'
> includes the substring 'libvirt', then it supports usable QMP even
> though the version claims to be only 0.12.xyz which normally did not
> have usable QMP.

I think we should keep the mess caused by __com.redhat_* commands and events
downstream only. We never added such support upstream and we should not start
doing that. It just make the code more complicated and ugly. Especially when
the downstream command and the upstream one differ in arguments, name or even
semantics. I know, we added support for recognizing downstream QEMU as QMP
capable but that's not the same playground. Without recognizing QMP
capability, downstream qemu would be mostly unusable while implementing
support for several downstream commands would only affect a few bleeding-edge
features.

Jirka