Re: [libvirt] [Qemu-devel] virDomainBlockJobAbort and block_job_cancel

On Wed, Dec 07, 2011 at 04:01:58PM -0700, Eric Blake wrote: > On 12/07/2011 03:35 PM, Adam Litke wrote: > > Stefan's qemu tree has a block_job_cancel command that always acts > > asynchronously.  In order to provide the synchronous behavior in libvirt (when > > flags is 0), I need to wait for the block job to go away.  I see two options: > > > > 1) Use the event: > > To implement this I would create an internal event callback function and > > register it to receive the block job events.  When the cancel event comes in, I > > can exit the qemu job context.  One problem I see with this is that events are > > only available when using the json monitor mode. > > I like this idea.  We have internally handled events before, and limited > it to just JSON if that made life easier: for example, virDomainReboot > on qemu is rejected if you only have the HMP monitor, and if you have > the JSON monitor, the implementation internally handles the event to > change the domain state. > > Can we reliably detect whether qemu is new enough to provide the event, > and if qemu was older and did not provide the event, do we reliably know > that abort was blocking in that case? I think we can say that qemu will operate in one of two modes: a) Blocking abort AND event is not emitted b) Non-blocking abort AND event is emitted The difficulty is in detecting which case the current qemu supports.  I don't believe there is a way to query qemu for a list of currently-supported events. Therefore, we'd have to use version numbers.  If we do this, how do we avoid breaking users of qemu git versions that fall between official qemu releases?