On Sat, Dec 31, 2005 at 09:52:49AM +0000, Keir Fraser wrote:
>
> On 31 Dec 2005, at 05:38, Cihula, Joseph wrote:
>
> >However, when the watch bookkeeping is combined with the transaction
> >bookkeeping (which is already there) this is a lot of duplication with
> >what xenstored already has to do for each connection. I'm wondering if
> >it wouldn't be better to add a sub-connection id to xenstored and
> >xenbus
> >so that each xenbus client would be seen by xenstored as a separate
> >(sub)connection. Then watches and transactions would not need any
> >special code in xenbus, as xenstored would handle the tracking and
> >cleanup.
> >
> >This method would either need to change the xenstore wire protocol or
> >co-opt the req_id field (which doesn't seem to be used). While some
> >additional code would have to be added to xenstored, I think that a
> >fair
> >amount of code (and many synchronization locks/mutexes) in xenbus could
> >be removed.
>
> How about add a new command XS_NEW_CONNECTION, taking a grant reference
> and an event channel? This would then set up a new inter-domain event
> channel and messaging memory page, and then commands would no longer go
> via the kernel at all.
>
> One drawback is it would then be very hard for the kernel to tell
> whether any xenstore transactions are in progress in user space. This
> is a problem since transaction state is not copied during save/restore.
> Either that needs to happen, or transactional xenstore code needs to
> handle 'spurious' failures at any point in a transaction (handle EAGAIN
> on any transactional read/write, not just on commit).
Could Xenstored not simply "save up" the EAGAIN until the commit? If a domain
migrated in the middle of a transaction, then Xenstored would see a
transaction handle that was invalid for that connection. In that case, it
could simply ignore all writes until a commit, in which case it would return
EAGAIN, just as if the transaction had seen a conflicting write.
I think that forcing clients to handle EAGAIN for all messages, not just
commit, would be undesirable.
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home