On 09/09/2016 04:30 PM, John Ferlan wrote:
+ /* Fix job completeness reporting. If cur == end mgmt + * applications think job is completed. Except when both cur + * and end are zero, in which case qemu hasn't started the + * job yet. */ + if (!info->cur && !info->end) {
We get here if qemu reports 0/0 (or if qemu reports nothing, and we end up with 0/0 because we 0-initialized the object)...
+ if (rawInfo->ready > 0) { + info->cur = info->end = 1;
if qemu reported done (on a no-op job), then we fudge to 1/1 and the caller knows we are done...
+ } else if (rawInfo->ready < 0) { + info->end = 1;
if qemu didn't tell us it was ready, then we fudge to 0/1. I thought the original email thread was that if rawInfo->ready == 0 (qemu explicitly told us it is NOT done) that we want to fudge to 0/1, and then the real question is that if qemu tells us nothing at all about rawInfo->ready, then fudging MIGHT treat a no-op job as never ending, so it was better to leave it at 0/0 (an application getting 0/0 when talking to new-enough libvirt then knows it is talking to older qemu). In other words, I think this condition is slightly better as rawInfo->ready == 0, and leave the rawInfo->ready < 0 case as 0/0. Or am I misremembering the results of the earlier thread?
+ }
Can info->ready == 0 ? w/ info->cur = info->end = 0
If so, then we're in the same mess or some other weird condition.
Seems like "ready" will be set in qemu during block_job_event_ready, so that would say to me that as long as the structure is allocated, ready will be false and conceivably info->cur = info->end = 0.
Wouldn't that mean the < 0 should be <= 0
<= 0 would make both explicitly not done and no answer from qemu mean the same thing - we fudge to 0/1 to tell the caller that it is not done. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org