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