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

[Michal Privoznik]

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

Michal