From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: /proc/xen/xenbus supports watch? Date: Mon, 19 Sep 2005 10:19:31 +1000 Message-ID: <1127089171.23870.56.camel@localhost.localdomain> References: <5d7aca9505090801025f3d5771@mail.gmail.com> <3d8eece205090803381b818f18@mail.gmail.com> <1126226609.25110.3.camel@localhost.localdomain> <3d8eece205091302422ac74f77@mail.gmail.com> <1126657264.7896.20.camel@localhost.localdomain> <1126689530.4415.10.camel@localhost.localdomain> <3d8eece205091405555a2871fc@mail.gmail.com> <1126748390.12119.33.camel@localhost.localdomain> <1126945564.29203.116.camel@localhost.localdomain> <20050917174003.GQ5722@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20050917174003.GQ5722@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian Limpach Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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