On 13.09.2016 11:52, Michal Privoznik wrote:
> 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
Oh, This should have been C/E instead of C/R. Current/End. 'e' and 'r'
keys are just too close to each other :-)
> ------+-------------+----------
> < 0 | 0/0 | 0/0
> = 0 | 0/0 | 0/1
> > 0 | 0/0 | 1/1
>
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list