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

[Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>]

On Mon, Sep 26, 2005 at 04:36:11PM +1000, Rusty Russell wrote:
> > I believe that the only thing we really _need_ at the moment
> > is support for multiple concurrent transactions.
> 
> You mean, on the same connection, I assume?

Yes.

Before I reply to the rest of your comments, I'd like to point out that
I don't agree with your assumption that we can delay suspend/resume
until we're outside of a transaction.  This seems to be the fundamental
difference driving different solutions.

> > This avoids
> > having to hold the lock except for very short periods
> 
> True, but is holding the lock a problem?  If we remove /proc/dev/xenbus
> from the equation, I don't think it is.  In fact, I think the lock is a
> very good thing, which is why I put it there.

I think holding the lock is not desirable.  For live migration, it might
even turn out to be a bottleneck if we have to serialize device reconnect.

> > and it
> > allows the server to return EAGAIN on operations where it doesn't
> > have the state corresponding to the transaction anymore.
> 
> Non sequiter, AFAICT.  We can have the server return EAGAIN on any
> operation, but that's independent of the kernel's locking strategy.  But
> you will have to make all the kernel code deal with it, as well as
> everyone using libxenstore.  Frankly, that's just stupid if we can
> easily avoid it.

You read what I wrote in the wrong context:  transaction ids are necessary
to distinguish operations which are part of a transaction from those
which are outside of transactions.  On suspend/resume, you need to
be able to decide either at xenstored level or better on the client side
(xenbus driver or libxenstore) whether you need to fail an operation
or not.

You can achieve the same by only supporting operations within a
transaction.

> > Since we
> > need to add some kind of transaction identifier to the interface
> > to support this, we should make this change now.
> 
> Or, alternately, since we don't need it, we shouldn't.

I think we need them since it's the simplest solution to the whole
multi-page/multi-connection issue for a saner xenbus_dev implementation:
- lock only held around xs_talkv
- transaction ids
- single point for demultiplexing watch events

    christian


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