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


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

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