From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: /proc/xen/xenbus supports watch? Date: Wed, 14 Sep 2005 10:21:04 +1000 Message-ID: <1126657264.7896.20.camel@localhost.localdomain> References: <5d7aca9505090801025f3d5771@mail.gmail.com> <3d8eece205090803381b818f18@mail.gmail.com> <1126226609.25110.3.camel@localhost.localdomain> <3d8eece205091302422ac74f77@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3d8eece205091302422ac74f77@mail.gmail.com> 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@cl.cam.ac.uk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Tue, 2005-09-13 at 10:42 +0100, Christian Limpach wrote: > On 9/9/05, Rusty Russell wrote: > > On Thu, 2005-09-08 at 11:38 +0100, Christian Limpach wrote: > > > On 9/8/05, NAHieu wrote: > > > > Anybody (Christian?) could please tell me if we can get the support > > > > for registering watch with /proc/xen/xenbus? (..OK, I know that we > > > > will change it this /proc stuff to a device soon) > > > > > > > > So far we can only do read/write/rm. I really miss the xen watch feature. > > > > At the moment, the xenbus device is a simple hack which grabs the lock > > on all store communication on open, and drops it on close. It's not > > really a general mechanism for tools in domUs to communicate with the > > store. > > Could we reduce the time we hold the lock to from before we call > xb_write until both data->bytes_left and data->awaiting_reply are 0 > again? I think this would work except for transactions, how do you > feel about supporting multiple transactions per connection? Should we > at least extend the interface now so that we can add concurrent > transaction support later, i.e. transaction start returning a handle > and all operations taking a handle argument? I think if we want to do this we should actually introduce a new mechanism for communications. There's no reason why a domain can't introduce more pages for xenstore communication beyond the one it is given to start with, is there? (OK, unintroduce needs to take a shared page instead/as well as a domid). So when someone opens the xenbus dev, we introduce a new page to the domain and the xenstored uses that for comms. When closed, the page is released. This actually simplifies the xenbus_dev driver a lot: now it's just a dumb pass-through since we don't have to worry about the userspace program blowing chunks all over the kernel's comms mechanism. I'll hack something up and see what you think... Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman