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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 27 Sep 2005, at 07:10, Rusty Russell wrote:

> 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.
The transactional code we have in drivers right now is actually very 
simple. Most of the problems we have had are mainly due to buggy code 
getting checked in due to insufficient testing. Kind of understandable 
-- hacking the front/back drivers isn't, noone feels like they own 
them, so they don;t get properly tested when changes like e.g., EAGAIN 
on commit get checked in. I see that as our main barrier to stability, 
not adding an identifier to transaction, nor returning EAGAIN from 
reads/writes within a transaction.
Look at the transactional loops we have. Already they are naturally 
structured with a retry label at the top, they (now) contain only 
idempotent actions, and all accesses are straightforwardly done within 
a single function. In these situations, handling EAGAIN from 
reads/writes is a total cinch, and avoids us needing to implement mad 
things like transaction migration in the future. Okay, so we might end 
up with somewhat more complicated transactions in the future, but 
really: how complicated are they likely to get? Not very, imo.
 -- Keir


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