Gerd Hoffmann wrote:
xenstore doesn't calls you back. xenstore gives you a file
handle you
can select() on and a function you can call when data is available to
figure which watch did fire.
Yes, my mistake. I was -- cough -- reading the kernel interface to
xenbus, not the xenstore userspace interface. As you rightly say the
userspace interface gives you a fd which you have to select() on, see
the C example here:
http://wiki.xensource.com/xenwiki/XenStoreReference
> We would also need to avoid mixing ordinary request/response with
the
> notifications
Why? Just disallowing notifications while a request is in flight should
be enougth I think.
I'd like to have something which integrates nicely with the usual
select() based event loops, like the xenstore model. Sort of "here is a
file handle, and if data comes in call this function." The function in
turn could either call callbacks or return some event struct.
I can see this working.
In the Xen (local) case we can hand back the Xenstore fd itself for
applications to monitor.
In the Xen remote case the server side has already got an event loop
which can look for fd events. They'll be sent synchronously to the
client. The client will have to hand out the remote connection fd for
applications to select() on.
In the qemu case I'm not sure how to modify qemu_driver.c to handle
this. One for Dan Berrange to comment on.
Rich.
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903