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


Re: [Xen-devel] xenbus_dev_request_and_reply()

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xenbus_dev_request_and_reply()
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Fri, 2 Mar 2007 20:28:48 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Mar 2007 12:24:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C20E1E63.A871%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070302181138.GA26225@xxxxxxxxxxxxxxxxxxxxxxx> <C20E1E63.A871%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Fri, Mar 02, 2007 at 06:33:07PM +0000, Keir Fraser wrote:

> > So if userspace gets killed during a transaction, we'll never be able to
> > suspend. And of course an invalid transaction end will panic the domain.
> > 
> > Unfortunately blktap is actually using transactions.
> xenbus_dev_release() aborts any in-progress transactions when the device is
> closed (e.g., due to process crash).

Ah, I see.

> I don't claim this is nice by the way. If I hasd time I would actually do
> transaction-id renumbering in the xenstore device driver (so application may
> see different number from the real physical transaction id): each
> application-visible identifier maps to a physical identifier or to XBT_NIL
> (if the transaction started before a save/restore). If it maps to XBT_NIL
> then reads/writes are done outside of a transaction and the transaction_end
> will always return 'fail'. This avoids needing to modify users of xenbus to
> deal with failure-return codes from reads/writes inside of transactions
> (which absolutely none of them do right now). Instead they'll get back some
> 'reasonable' data values and continue on to the transaction_end request,
> which they *can* handle failure of.

Hmm, it would be simpler and better to just fix the users, but there's
simple way to tell that it failed due to an invalid transaction ID
unfortunately, so I suppose something like this will be necessary...


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>