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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
