On Sun, 2005-09-25 at 19:55 +0100, Christian Limpach wrote:
> On Sun, Sep 25, 2005 at 12:33:33PM +0100, Keir Fraser wrote:
> > Also, page-per-connection won't entirely avoid sharing of
> > state/resource in xenstored. At some point we'll want to add per-domain
> > access policy, and space/bandwidth quotas (to prevent DoS). All of
> > those must be shared between the multiple connections of a domain -- so
> > the separate connections aren't as independent as you might like.
>
> 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?
> 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.
> 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.
> 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.
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home