On 04/10/2012 11:24 AM, Daniel P. Berrange wrote: >>> As of this[1] qemu email, both commands have been proposed but not yet >>> incorporated into the tree; in fact, the implementation I tested with >>> has changed to match this[2] email that suggested a mandatory >>> 'full':'bool' argument rather than 'mode':'no-backing-file'. So there >>> is a risk that qemu 1.1 will have yet another subtly different >>> implementation. >>> [1]https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01524.html >>> [2]https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg00886.html >> >> >> None of this gives me warm fuzzies :-/ > > Based on previous experience, my suggestion is that we do *not* merge > any of this new libvirt API work, until the QEMU stuff has actually > been accepted into their git master. The previous block streaming > stuff is a nice history lesson in what happens when we merge stuff > in libvirt before QEMU has agreed their final design :-( I'll push hard on the qemu folks to at least commit to the qapi for qemu 1.1, even if the implementation is not available until after that point, but I can live with the decision to not push the parts depending on the new monitor commands. This brings up some corollary questions: patch 3/18 depends on the new monitor command only insofar as it uses the existence of the command as a way to sanely tell if 'block_job_cancel' is asynchronous or synchronous. I may be able to rework that into something that doesn't depend on 'drive-mirror's existence, by instead tracking whether an event has been issued; is it worth me spending time on this effort, or should I wait for the qemu reaction to committing to 'drive-mirror' first? patch 2/18 and 4/18 are independent fixes, which could be pushed now without waiting for 1/18. Should I pursue this course of action? It is only in 1/18, as well as in 5/18 and later, where we are treading on the dangerous ground of committing to a libvirt API without a reference implementation in qemu; and even then, we can choose whether to commit to the libvirt API without immediate qemu support. All that said, I'd still appreciate a review of the full series, to catch any other potential mistakes while the code is still fresh on my mind, even if we delay pushing it to libvirt.git until qemu has made more progress. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list