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

[Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>]

On Thu, Sep 15, 2005 at 11:39:50AM +1000, Rusty Russell wrote:
> On Wed, 2005-09-14 at 13:55 +0100, Christian Limpach wrote:
> > On 9/14/05, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> > > Patch for reading only (I subbed in NULL for the default store page for
> > > the moment, since I know there's another patch out there which touches
> > > this).
> > 
> > I really don't think that the multi-page approach is good and it's
> > also orthogonal, i.e. we could have multiple connections but still
> > want concurrent transactions on the same connection.  What's wrong
> > with concurrent transactions on the same connection?
> 
> You're right it's orthogonal, but we really do want separate connections
> for each client: they're logically separate, so overloading them on one
> transport is going to be a hack.  Inside the kernel we do it to a
> limited degree, but already have a proxy for handling watches and we
> trust everyone to get it right and use One Big Lock.

I think it's not even a hack by your definition because at least for
the uses why I added the device (backend device setup from hotplug
scripts), it is logically the same client.

It seems to me that the solutions we want are extremely opposite:
- multiple pages with single connection and single transaction
- single page with single connection and multiple transactions

My main objections against multiple pages are:
- setup/teardown overhead: we'll have to add messages to setup
  and teardown a new connection
- we have to maintain state about the connection in the daemon
- save/restore becomes more complicated

> Now, we still might want concurrent transactions for a single user, but
> more likely we want to get rid of the "root of transaction" model
> altogether, since noone likes it, and there's an unrelated issue with
> NFS-root mounted store (it breaks horribly) that is likely to change our
> underlying (on-disk directory-based) implementation.  Thoughts?

I'd like us to extend the message format so that we can support
concurrent transactions in the future, i.e. have transaction_start
return a transaction handle and have everything else support a
transaction handle.  We can return 0 as the handle for now and
also use 0 for outside of transaction operation.

    christian


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