[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] /proc/xen/xenbus supports watch?
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |