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