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 notificationsWhy? 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list