Re: [Qemu-devel] [PATCH] Further tidy-up on block status

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

14.12.2016 21:17, Alex Bligh wrote:
>> On 14 Dec 2016, at 17:55, Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> wrote:
>>
>>> Hmmm... Well in the '*' case, it's up to the namespace as to how it parses things, so '*' could be prohibited entirely or mean 'return the first 20 matching' or similar. So that's less of a problem. And 'set all' doesn't exist (unlike 'list all').
>>>
>>> I think in the LIST case we should allow the server to omit contexts under certain circumstances, and allow SET to return ETOOBIG.
>>>
>> We can't prohibit '*' as query string as implementation defined. And we shouldn't (I think) define its meaning.
> Those two statements appear to me to contradict each other. The current documentation *does* define the query string (to the right of the colon) as implementation defined. I'm thus not sure what you mean.
>
>> Opposite, we can define, that query must not select more than 20 contexts, but I'm not sure that this is good.
> Each query can select from only one namespace in the current document (Wouter explained why). However, you can specify multiple queries.
>
> I don't think we need to define a hard limit of a particular number.
>
>> So, do you mean
>>
>>   list('backup:modtime>*') -> empty list
> The result of that would depend on however the 'backup' context was defined, meaning it had the options of:
> * ETOOBIG
> * Listing some subset of available contexts (arguably 'none' is a subset)
>
>>   set('backup:modtime>*') -> ETOOBIG
> Again, the result of that would depend on however the 'backup' context was defined, meaning it had the options of:
> * ETOOBIG
> * Listing some subset of available contexts (arguably 'none' is a subset)
> ... and it need not make the same choice as above, but I agree it would be logical for it to do so.
>
> As any form of wildcarding within a query refers to one particular namespace (as a query by its nature specifies a single namespace), we don't have to worry about the way wildcarding works in the standard, as Wouter pointed out. We merely need to provide that ETOOBIG and listing a subset are acceptable responses.
>
> What we do need to decide is what the response to list() (i.e. a list with a zero length list of queries) does. It's currently defined to return every context from every namespace. Options would include
> * ETOOBIG
> * Listing some subset of available contexts (arguably 'none' is a subset)
> * Allowing abbreviation of algorithmically specified contexts (e.g. in this case just returning 'backup:' to represent all available backup contexts)

Shouldn't we add some flags to REP_META_CONTEXT, for client to be 
insure, is returned string a direct context name or some kind of 
wildcard?|| Just a flags field, with one flag defined for now: 
|NBD_REP_META_CONTEXT_LEAF and others reserved.|


-- 
Best regards,
Vladimir