[Xen-tools] Re: [PATCH 1/3] Recover transaction on restart, give transactions IDs

[Rusty Russell <rusty@xxxxxxxxxxxxxxx>]

On Tue, 2005-09-27 at 05:58 +0100, Christian Limpach wrote:
> That's because you can write all this code much simpler if you
> do something like:
>  again:
>   ...
>   err = xs_xxx(yyy);
>   if (XS_CHECK_ERR(err, again))
>     real error path
> 
> with:
> #define XS_CHECK_ERR(err, label) ({   \
>       if ((err) == -EAGAIN)           \
>               goto label;             \
>       (err);                          \
> })
> 
> That keeps all the code just as simple as it was before we had
> to handle EAGAIN everywhere.

Hiding control paths in macros is always a bad idea.  Forcing people to
use macros to use your code is bad to start with; look at the horrible
driver code we now have trying to handle zero-length files because xend
didn't use transactions.  Add that to the handling of backends without
frontends because of lacking transactions.  Add the individual drivers
having to handle EAGAIN from transaction commit, and read the FIXMEs.
Then add the use of UUIDS, which in addition to being hard to read,
adding a new abstraction and yet being of no current use, mean we have
to jump through hoops to get a unique in-kernel bus id.

Also, you want to add multiple concurrent transactions, and Keir wants
to get rid of the xenbus_lock so can they run in parallel.

And these are just the decisions I've been directly involved with.  No
surprise that we've made an undebuggable, unmaintainable mess so far.
And yet the default is still "yes" to new features, new requirements and
more complex APIs.  I seem to spend most of my time recently asking for
justifications for adding stuff; it'd be faster and much, much more fun
just to give in and code it up.

Worse is better.
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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