| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] watches not working from domU userspace
On Thursday, December 22, 2005 7:34 AM, Ewan Mellor
<mailto:ewan@xxxxxxxxxxxxx> wrote:
> On Thu, Dec 15, 2005 at 03:33:08AM -0800, Cihula, Joseph wrote:
>
>> It seems that xenstore watches do not work from domU userspace (they
>> obviously do for drivers).
>>
>> In some preliminary debugging of this, there are two aspects of the
>> failure: not sending the watch to xenstore and not handling watch
>> events for userspace watches. The former can be easily fixed by
>> adding the missing 'case XS_WATCH:' to xenbus_dev_write() in
>> xenbus_dev.c. The latter is more difficult to fix. So before I
>> tackle it, I wanted to see if anyone else was already working on a
>> solution or just had some thoughts to share on possible solutions.
>
> No-one's working on this at the moment, as far as I am aware, and you
> are more
> than welcome to attack the problem. The problem is that the
> interface exposed
> through /proc/xen/xenbus does not handle the demultiplexing of watch
> events
> when they fire. It's only simple bookkeeping that is missing:
> userspace
> processes will need to block on reading /proc/xen/xenbus, and then
> you need to
>
> o keep track of every register event so that you can demux the
> correct
> watches firing and unblock the correct reader;
> o tear down the state that you hold internally whenever someone
> sends an
> unregister message;
> o if the connection to userspace is closed before the watch is
> unregistered, unregister it on their behalf;
> o deliver watches to the kernel correctly too.
>
> The interface presented through /proc/xen/xenbus should be the same
> as that
> presented through the unix domain socket used by dom0, so you should
> be able
> to borrow lots of code from the existing xenstore library and move
> that into
> kernel space.
>
> Cheers,
>
> Ewan.
This is the approach that I've taken so far (I had to pause my work to
finish up another project).
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.
What do you think?
Joseph Cihula
(Linux) Software Security Architect
Open Source Technology Center
Intel Corp.
*** These opinions are not necessarily those of my employer ***
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home