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/
Home Products Support Community News


Re: [Xen-tools] Re: xenbus block device support

On 13 Aug 2005, at 10:56, Rusty Russell wrote:

You are the second person from Cambridge to query this; strange that I
thought it obvious.

The Unix experience with EINTR has shown, dramatically and repeatedly,
that these kind of spurious failures make for unreliable systems.  It's
a shockingly bad API, at best a 7 on the Hard to Misuse scale.

There are times when we must, reluctantly, admit failure and sacrifice
the beauty of others' code upon the rock of our requirements.  This is
not one of those times.

Even if we don't have EAGAIN, xenstore users have to be prepared that work they do based on transactions they have just completed may be invalidated by other system components. For example, a frontend driver may have to connect to a new backend arbitrarily soon after it has connected through to the old one, because of a driver restart.

Support for this kind of 'shifting sands' has to be a fundamental part of the design for things like xenbus and xend, or the system can never be properly reliable. And once you have that, I see little difference between redoing work because a transaction failed vs. redoing work because a watch fired.

Maybe this is something we can leave for now. Specifying roots up front seems a bit weird to me, but I guess you do generally know what area of the store you will be working in, and you can always default to '/'. :-) And xenbus can be robustified for EAGAIN later, if someone implements an OCC version of xenstore.

 -- Keir

Xen-tools mailing list