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