On 04/10/2012 03:30 PM, Eric Blake wrote:
>
> Okay, as I understand it, the only qemu binary that has a synchronous
> block_job_cancel command is the version that is part of RHEL6.2. So any
> compatibility code to allow for a synchronous block_job_cancel command
> in qemu would only ever make a difference for someone who built from
> upstream libvirt sources (or post-RHEL6.2 source rpm) to run on RHEL6.2
> (and *didn't* build a post-RHEL6.2 qemu). Is that correct?
Correct, that's how I understand it. I'm cc'ing Adam and Stefan in case
I missed something, though.
And based on what we decide with qemu making it possible to detect
async
block cancel differently from RHEL 6.2 (see this email[1]), it would be
reasonable to push this patch even if we defer the rest of the series.
[1]
https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01111.html
Qemu just made it possible to tell the two apart. Luiz has accepted
this patch[1] into the qmp queue, which means:
RHEL 6.2 -> block_job_cancel, synchronous
qemu 1.1 -> block-job-cancel, asynch
[1]
https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01225.html
I'm assuming (hoping, really) that RHEL 6.3 will likewise go with the
qemu 1.1 naming, since RHEL 6.3 is committed to the async interface.
But that means I need to respin this patch to deal with the two namings
for the two behaviors. I'll split the async block-job-cancel handling
into a separate series that can be applied right away (as upstream qemu
is now committed to it), in contrast with the rest of this series
dealing with 'drive-mirror' that is still in a state of upstream flux.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org