Re: /proc/xen/xenbus supports watch?

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

On Sat, 2005-09-17 at 18:40 +0100, Christian Limpach wrote:
> On Sat, Sep 17, 2005 at 06:26:04PM +1000, Rusty Russell wrote:
> > What was the reason for wanting multiple transactions per connection?
> > Changing the interface is going to be a PITA, so we should figure out if
> > we're going to need that soon...
> 
> It solves the immediate problem of making the xenbus lock in the kernel
> driver more fine grained.  I'm not too happy with how a userspace
> program can block all xenbus access for that domain at the moment,
> even if this is limited to the root user.

Sure, and we already have the concept of separate transports, so I think
we should use them.

> Additionally, I believe
> it's necessary to support reconnect to a different store after
> restore, allowing the store daemon or the xenbus driver to distinguish
> operations which are part of an incomplete transaction from operations
> which are not part of a transaction at all.

And I think you're wrong; it's unnecessary and it doesn't actually help.
The code will show.

>   Finally, adding transaction
> ids later will be a lot more difficult.

Unless we introduce a xs_transaction_context() call, and leave it
implicit?

> I also find the current behaviour a bit odd, we support operations
> outside of transactions but once you start a transaction, every
> operation you make is part of that transaction.  i think we should
> either require to always be in a transaction or always allow outside
> of transaction operations.

We could drop implicit transactions; it would simplify the code a bit.
I didn't do this because it seems a bit silly for simple monitoring
tools.  The start/end transaction model is simple, but if it's
demonstrably insufficient, I agree we should go for transaction ids.

That's orthogonal to the multiplexing of connections over a single
transport tho.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman