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