Re: /proc/xen/xenbus supports watch?

[Rusty Russell <rusty@rustcorp.com.au>]

On Thu, 2005-09-22 at 10:35 +0100, Keir Fraser wrote:
> Whatever, the client probably needs the code to realise that a bad 
> thing has happened and to take appropriate action whichever strategy we 
> go for. I suspect they are equivalent complexity for clients.

I think you've summed it up well.  Of these two I'm leaning towards
EAGAIN (which the client can turn into a fake success if they want).
But both are subtle and kinda icky.

Which is why I am pondering a bundle/unbundle interface for
transactions, so we can migrate them with the domain.  Summary: 

1) Easy to do at the moment: we already snapshot the entire store for
transactions, so we can just bundle/unbundle that.  We need
globally-unique transactions IDs, but that's fairly simple.
2) Each domain adds roughly 5k to the store (this will increase, say
10k).  This means migrating off a node with 100 domains means adding 1M
to the data we have to send *per transaction*.
3) The store compresses extremely well (~800 bytes per domain), so we
could trivially get it down to 160k/transaction in the 100 domain case.

You know I treasure simple APIs, and this makes the store API simpler
and so reduces subtle errors in future.

But is it worth the complexity?
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman