On Fri, 2005-08-26 at 11:28 +0100, Christian Limpach wrote:
> On Fri, Aug 26, 2005 at 10:20:44AM +1000, Rusty Russell wrote:
> > 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?
This is why suspend takes the xenbus_lock; it just doesn't make sense
otherwise (even without transactions, you could have issued half a
command, then get migrated to another machine and another store, and
you'd be screwed).
> > 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?
For xenbus, we can do it either way. But for the tools, we really need
xenstored to do it, because we need the data to appear in the socket.
So I think I'll mod xenstored to do it, even though it's a little extra
traffic (in theory, xenstored could optimize this away if the node has
*never* existed, but doesn't seem worth it).
> > > 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...
OK, I wasn't sure if xenstored should do this, or have the tools do it.
I'll look at the xenstored mods...
Thanks!
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools
|
Home