Re: [Qemu-block] [PATCH v3 18/19] nbd/client: Work around 3.0 bug for listing meta contexts

[Eric Blake]

On 1/17/19 2:07 AM, Vladimir Sementsov-Ogievskiy wrote:
> 17.01.2019 6:21, Eric Blake wrote:
>> On 1/16/19 9:43 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
>>>> @@ -839,9 +842,25 @@ static int nbd_list_meta_contexts(QIOChannel *ioc,
>>>>
>>>>            ret = nbd_receive_one_meta_context(ioc, 
>>>> NBD_OPT_LIST_META_CONTEXT,
>>>>                                               &context, NULL, errp);
>>>> +        if (ret == 0 && seen_any && !seen_qemu) {
>>>> +            /*
>>>> +             * Work around qemu 3.0 bug: the server forgot to send
>>>> +             * "qemu:" replies to 0 queries. If we saw at least one
>>>> +             * reply (probably base:allocation), but none of them were
>>>
>>> if we are saying about 3.0, it is base:allocation for sure, isn't it?
>>>
>>>> +             * qemu:, then run a more specific query to make sure.
>>
>> If the server is qemu 3.0, then yes, it is base:allocation. But it could
>> be some other server that has its own custom return without implementing
>> base:allocation.
> 
> Indeed) And in this context, heuristic about that server should have at least 
> one
> context listed with no query seems not generic. Why not query 'qemu:' even if 
> empty
> query returns nothing?

Because it is highly unlikely that we will ever encounter a server that
knows how to serve "qemu:" contexts but not "base:allocation" (qemu is
not such a server, and why would any other server bother with qemu:
specific information?).

> So, at least, "probably" is imbalanced with this not described
> in comment heuristic which seems bound to 3.0.

qemu 3.0 is the only server where the heuristic will make a difference,
but not the only server where the heuristic may trigger.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature