[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xenbus_dev_request_and_reply()


  • To: John Levon <levon@xxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 02 Mar 2007 18:33:07 +0000
  • Delivery-date: Fri, 02 Mar 2007 10:32:25 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acdc+Tigd3ZGwMjsEdusCwAX8io7RQ==
  • Thread-topic: [Xen-devel] xenbus_dev_request_and_reply()

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.