Re: [Xen-devel] Xenstore watch interface in the kernel

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, December 22, 2016, 1:22:06 PM, you wrote:

> Juergen Gross writes ("Xenstore watch interface in the kernel"):
>> While working on the Linux xenbus kernel driver I stumbled over a rather
>> strange interface: a Xenstore watch event is delivered via a callback
>> defined as:
>> 
>> void (*callback)(struct xenbus_watch *,
>>                          const char **vec, unsigned int len);
>> 
>> vec is an array of strings and len the number of strings in that
>> array.
>> 
>> Looking at the Xenstore interface I don't see how there could ever be
>> an array with another len than 2 be presented (the first string being
>> the modified path, the second the token specified when registering
>> the watch).

> Yes, this is an anomaly.

> IIRC (from the last time I looked at this) a long time ago in a galaxy
> far far away someone thought it might be a good idea to introduce some
> kind of payload to watch events, so that watches could be explicitly
> fired with a payload.

> However, this wasn't in any deployed implementation.

Something I did ran into while trying to use xenstore, was that the callbacks
don't give back the previous and current value.
So you don't really know *how* the state changed, unless you keep all change 
locally as well.
I have circumvented it the dirty way, by setting the token as the current
value, but it isn't very pretty and all setters must adhere to that, so it's 
not 
working for the general Xen entries and therefor only useful for my own entries.

Any idea as to why the callback doesn't return the current and previous value
directly ?
--
Sander

>> I'd like to modify the callback's prototype to:
>> 
>> void (*callback)(struct xenbus_watch *,
>>                          const char *path, const char *token);

> I think this would be a fine idea.

>> Is there any reason not to change the interface in the kernel?

> No.

>> BTW: The handling of more than 2 strings as watch event parameters is
>> even repeated in the interface to libxenstore. I looked through the Xen
>> sources and could find no use of the number of strings returned in case
>> of a watch event. While we can't change the interface of libxenstore
>> I don't think we have to be prepared for an arbitrary number of strings
>> for a watch event at the kernel interface.

> Yes.

> Ian.




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