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

To: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Subject: [Xen-tools] Re: [PATCH 1/3] Recover transaction on restart, give transactions IDs
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Tue, 27 Sep 2005 14:37:10 +1000
Cc: Xen Tools <xen-tools@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Delivery-date: Tue, 27 Sep 2005 04:34:36 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050926185733.GG10661@xxxxxxxxxxxx>
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
References: <1127734218.26244.1.camel@xxxxxxxxxxxxxxxxxxxxx> <20050926185733.GG10661@xxxxxxxxxxxx>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2005-09-26 at 19:57 +0100, Christian Limpach wrote:
> Rusty,
> I don't agree with this approach since it relies on the fact that
> we won't suspend/resume within a transaction.

If we suspend/resume over transactions, this mechanism will not work by
itself, it will still work for local tools over xenstored restart.

But transactions are a privileged operations (either in-kernel
or /proc/xen/xenbus), and are short, so I don't see it as being an
issue.  If it becomes an issue, I'd much rather do transaction migration
than present a horrible API to xenstore users for such a corner case.

As predicted, the change to have xs_transaction_end return EAGAIN made
the kernel code uglier and caused bugs (thanks Keir for the fixes so
far).  Returning EAGAIN from arbitrary operations is going to make it
worse.  I'm convinced we don't want to go there.

A bad analogy is like a leaky screwdriver -- Richard Braakman

Xen-tools mailing list