WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] /proc/xen/xenbus supports watch?

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel