WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-tools

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

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: [Xen-tools] Re: [PATCH 1/3] Recover transaction on restart, give transactions IDs
From: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Date: Tue, 27 Sep 2005 05:58:15 +0100
Cc: Xen Tools <xen-tools@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Delivery-date: Tue, 27 Sep 2005 04:55:50 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1127795830.7703.27.camel@xxxxxxxxxxxxxxxxxxxxx>
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> <1127795830.7703.27.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Tue, Sep 27, 2005 at 02:37:10PM +1000, Rusty Russell wrote:
> > 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.

Yes!

> 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.

No, please don't go there, transaction migration is a horrible idea!

> 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.

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.

    christian


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