Re: [libvirt] [PATCH 2/2] virDomainGetBlockJobInfo: Fix corner case when qemu reports no info

On 12.09.2016 21:19, Eric Blake wrote: > 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? So, just to make it crystal clear, is this what you're saying? ready | initial C/R |fudged C/R

------+-------------+---------- < 0 | 0/0 | 0/0 = 0 | 0/0 | 0/1 > 0 | 0/0 | 1/1