On 07/15/2015 10:34 AM, Peter Krempa wrote:
Introduce helper function that will provide logic for waiting for
block
job completion so the 3 open coded places can be unified and improved.
This patch introduces the whole logic and uses it to fix
cmdBlockJobPull. The vshBlockJobWait funtion provides common logic for
s/funtion/function/
block job waiting that should be robust enough to work across all
previous versions of libvirt. Since virsh allows to pass user-provided
s/allows to pass/allows passing/
strings as paths of block devices we can't reliably use block job
events
for detection of block job states so the function contains a great deal
of fallback logic.
---
tools/virsh-domain.c | 326 ++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 244 insertions(+), 82 deletions(-)
+/**
+ * vshBlockJobWait:
+ * @data: private data initialized by vshBlockJobWaitInit
+ *
+ * Waits for the block job to complete. This fucntion prefers to get an event
s/fucntion/function/
+ /* for two-phase jobs we will try to wait in the
synchronized phase
+ * for event arival since 100% completion doesn't necessarily mean that
s/arival/arrival/
+ * the block job has finished and can be terminated with
success */
+ if (info.end == info.cur && --retries == 0) {
As I said in the other patch, if info.end == info.cur and they are
non-zero, that SHOULD be equivalent to the job being complete (a
blockpull finishing, or a two-phase job transitioning to synchronized);
where it gets tricky is if the two are equal but zero (as some jobs can
validly have info.end == 0, but most jobs just see info.end as 0 before
getting into the main loop of the job). But it looks like you are doing
okay here.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org