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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools