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

Re: [Xen-devel] xenbus_dev_request_and_reply()

To: John Levon <levon@xxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xenbus_dev_request_and_reply()
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 02 Mar 2007 18:33:07 +0000
Delivery-date: Fri, 02 Mar 2007 10:32:25 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070302181138.GA26225@xxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acdc+Tigd3ZGwMjsEdusCwAX8io7RQ==
Thread-topic: [Xen-devel] xenbus_dev_request_and_reply()
User-agent: Microsoft-Entourage/11.2.5.060620
On 2/3/07 18:11, "John Levon" <levon@xxxxxxxxxxxxxxxxx> 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).

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.

 -- Keir


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

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