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

[Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>]

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