WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] XenStore Watch Behavior

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] XenStore Watch Behavior
From: John McCullough <jmccullo@xxxxxxxxxxx>
Date: Mon, 28 Aug 2006 17:48:31 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, John McCullough <jmccullo@xxxxxxxxxxx>
Delivery-date: Mon, 28 Aug 2006 17:49:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1177152.1685%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, John McCullough <jmccullo@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
References: <20060826203222.GA2835@xxxxxxxxxxx> <C1177152.1685%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
On Sun, Aug 27, 2006 at 03:57:06PM +0100, Keir Fraser wrote:
> On 26/8/06 9:32 pm, "John McCullough" <jmccullo@xxxxxxxxxxx> wrote:
> 
> >     What is the intended behavior of watches on the XenStore?  Should
> > only one watch be allowed on a given sub-hierarchy?  Should the most
> > specific watch be triggered alone?  Should all watches be triggered?
> 
> I believe it's all supposed to work in a very obvious and simple way: All
> watches registered on a prefix of the updated node's path should be fired. A
> single transaction can fire the same watch multiple times if that watch is
> on a common prefix of a number of nodes updated by that transaction (since
> each firing event specifies the full path of the modified node, so events
> can't really be merged).
> 
> If you observe different behaviour from this then it is most likely a bug
> and we would love to receive patches!
>

I am attaching a band-aid style patch for xswatch.  I haven't dug very
far into the xenstore code yet, and I'm not sure how much time I have to
dedicate on this quite yet.

What this patch addresses is xswatch's tendency to receive watches for
non-xswatch created watches with those tokens.  Is the indended behavior
of read_watch to pick up on all available watches and leave you to
discriminate which to service based on token?

Something that has recently perplexed me, is when using the watch during
the save/restore process, my handler won't receive watches where the
value written in the store has an underscore.  In the shutdown
situation, the underscore value is passed.  I am at a loss to guess why
this is happening.

-John

Attachment: xswatch-fix.diff
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel