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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/12/16 12:59, Juergen Gross wrote:
> On 22/12/16 13:49, Sander Eikelenboom wrote:
> > 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 ?
> This can't work: imagine two changes of the same node made in a very
> short time. There is no guarantee which watch event would reach you
> first, so the information regarding the old and new contents could be
> really confusing:
>
> node has value A
> is changed to B
> and then to C
>
> You could see the watch events:
>
> value changed from B->C
> value changed from A->B
>
> So either you would end up with the wrong new value "B" or you could
> track the contents in order to detect the reverse order of events,
> but this wouldn't be better than now.
You can also set watches on keys which don't exist yet, and have they 
watch fire when the key appears.  Distinguishing between not existing 
and having an empty value can't be done with just the previous content 
being sent.
~Andrew

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