[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] watches not working from domU userspace
On Saturday, December 31, 2005 1:53 AM, 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). > > -- Keir It seems like this would add a lot of overhead. Xenstore commands are typically only a couple hundred bytes and since they are synchronous (per client and excluding watches), this would leave a lot of the page unused. Moreover, for transient clients, such as xenstore-{read, write, rm}, the extra setup/teardown would also add to the cost. Joe _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |