[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] Re: Asynchronous notifications of domain start/stop



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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]