Re: [PATCH for-4.6 4/8] docs/libxl: Re-specify XENSTORE_DATA as EMULATOR_XENSTORE_DATA

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 29/07/15 10:35, David Vrabel wrote:
>
>> +EMULATOR\_XENSTORE\_DATA
>> +------------------------
>>  
>> -A record containing xenstore key/value pairs of data.
>> +A set of xenstore key/value pairs for a specific emulator associated with the
>> +domain.
>>  
>>       0     1     2     3     4     5     6     7 octet
>> -    +-------------------------------------------------+
>> -    | xenstore key/value pairs                        |
>> +    +------------------------+------------------------+
>> +    | emulator_id            | index                  |
>> +    +------------------------+------------------------+
>> +    | xenstore key/value data                         |
>>      ...
>>      +-------------------------------------------------+
>>  
>> +Xenstore key and value data are encoded as a pair of NUL terminated C
>> +strings.  Keys shall be relative to to the device models xenstore tree for the
>> +new domain
> This isn't quite descriptive enough, suggest:
>
>    "Xenstore key/value data is encoded as a packed sequence of (key,
>     value) tuples.  Each (key, value) tuple is a packed pair of NUL
>     terminated UTF-8 encoded character strings.  The keys are relative
>     to..."
>
> In particular, it is essential that character strings have a well
> defined encoding (I always recommend UTF-8) but the Xenstore protocol
> may specify a different encoding (perhaps ASCII?).

The best I can find is from xenstore.txt which says:

While xenstore and most tools and APIs are capable of dealing with
arbitrary binary data as values, this should generally be avoided.
Data should generally be human-readable for ease of management and
debugging; xenstore is not a high-performance facility and should be
used only for small amounts of control plane data.  Therefore xenstore
values should normally be 7-bit ASCII text strings containing bytes
0x20..0x7f only, and should not contain a trailing nul byte.

I don't think it is wise to constrain the record format further than
xenstore permits.

>   The data may also be
> better specified as a NULL-terminated octet sequence (rather than
> characters).

I will opt for octet sequence, and state that it should be encoded
suitably for xenstore, without actually being more specific.

~Andrew