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

[Rusty Russell <rusty@xxxxxxxxxxxxxxx>]

On Tue, 2005-09-13 at 10:42 +0100, Christian Limpach wrote:
> On 9/9/05, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> > On Thu, 2005-09-08 at 11:38 +0100, Christian Limpach wrote:
> > > On 9/8/05, NAHieu <nahieu@xxxxxxxxx> 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


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