WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

On Mon, 2005-09-26 at 19:51 +0100, Christian Limpach wrote:
> 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.

Absolutely.  The delays will be immeasurably short.  The code will be
simple.  The API will be simple.  Locking will be simple.  Drivers will
be simple.  Debugging will be simple.  Parallelism is not going to make
restore faster, in fact, the current "winner takes all" transaction
model means they'll be much, much slower.

Now, since this is really my last email before I head off on leave,
you're going to decide this without my bitching and moaning (yeah, I
know how much you'll miss it!).

Nonetheless, I'm happy to hand xenstored to your capable hands.  When I
come back, I might start writing tests or something equally
uncontroversial 8)

Cheers!
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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