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-tools

Re: [Xen-tools] [PATCH] Xenstore mkdir/write implicitly create directori

On Fri, Aug 26, 2005 at 10:20:44AM +1000, Rusty Russell wrote:
> > Maybe it's preferable to make the store users deal with most of this after
> > all.  We already know how to re-install watches, so triggering that code
> > path when the store starts up again would take care of the watches.
> 
> Yes, moving watch reinitialization into the library and allowing for
> spurious watch events (which IMHO clients should handle anyway) solves
> the watch problem quite nicely.  And it's almost free (a little more
> state in the library, but that's OK).

Agreed.  We could even have a xenstored mode where it randomly fires
watches to confirm that clients behave correctly.

> > We will have to deal with transactions failing anyway, so if the store
> > restarts in the middle of a transaction, we just return a non-fatal
> > failure code and have the user deal with that.
> 
> Well, we currently don't spuriously fail transactions, because we use
> locking to prevent overlapping transactions.  As I've argued repeatedly,
> this makes for a nicer programming model.

How do you handle transaction timeouts then?  After all, a guest can
get suspended for an arbitrary amount of time and at some point
xenstored will have to timeout the transaction and then what?

> >   Finally, I think we
> > should have watches fire when they get first installed (and re-installed),
> > if the node exists.
> 
> In general, we have to fire whether it exists or no: it might have been
> deleted.

yes.

> >   The current model where we install a watch and then
> > run the watch code manually doesn't work too well because the context
> > we're in is most likely not the same context we would be in when the
> > watch fires regularly.
> 
> Agreed; changing registration to explicitly fire the watch would
> simplify things.

Could you fix xenstored to do this?  Or is it better done inside
the xenbus driver?  Do we also need a function to wipe all the watches
for a domain to make sure that when we re-install watches we don't end
up with doubles?

> > Anything else?
> 
> Domain introductions are the other persistence issue, but they are also
> fairly simple.  Indeed, they should be placed in the store...

Sounds good.  I think we also need xenstored to watch for the domain
exception virq and remove domains which are dying...

   christian


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