[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/3] docs: add DIRECTORY_PART specification do xenstore protocol doc



On 08/05/17 12:09, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 2/3] docs: add DIRECTORY_PART specification do 
> xenstore protocol doc"):
>> DIRECTORY_PART was missing in docs/misc/xenstore.txt. Add it.
> ...
>> +DIRECTORY_PART              <path>|<offset>         
>> <gencnt>|<child-leaf-name>|*
>> +    Same as DIRECTORY, but to be used for children lists longer than
>> +    XENSTORE_PAYLOAD_MAX. Input are <path> and the byte offset into
>> +    the list of children to return. Return values are the generation
>> +    count <gencnt> of the node (to be used to ensure the node hasn't
>> +    changed between two reads: <gencnt> being the same for multiple
>> +    reads guarantees the node hasn't changed) and the list of children
>> +    starting at the specified <offset> of the complete list.
> 
> The "generation count" is not defined anywhere else in this protocol
> spec, so shouldn't be referred to here without definition.  We should
> explicitly state whether using a transaction is sufficient to ensure
> that this check will never fail.

As the generation count is if no interest anywhere else in this protocol
I don't see why the definition given in parentheses isn't enough.

The solution with <gencnt> was explicitly demanded in order to _not_
have to use transactions. So referring to transactions now seems to be
counterproductive.

> Taken together, I think the right approach is to specify a method to
> use this and to say that if a different method is used, the results
> are not reliable.

So libxenstore is using DIRECTORY_PART without transactions and will
still deliver correct results.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.