On Wed, Jul 18, 2007 at 03:45:10PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>Instead we should provide an API which lets application
>register callbacks for adding/removing file handles to an event loop.
Understood ...
>We in fact already have this - look at the src/event.h file. So if we make
>this part of the official public API, then applications merely need provide
>an impl of the virEventAddHandleFunc and virEventRemoveHandleFunc. The
>underlying libvirt drivers can thus invoke these callbacks as required,
>be it with the XenStored filehandle, a XenAPI filehandle, a libvirtd fd
>or something else.
If I understand what you're saying here, you are proposing that libvirt
provides a call like this following (don't worry about specifics):
virEventDomainNotify (virConnectPtr, int state, void (*f)(...));
The implementation of this call is that it sets up a xenstore watch, and
registers the xenstore fd with the previously defined
virEventAddHandleFunc (implemented by the main app / app's event loop code).
When the event happens, xenstore fd gets some data available, app's
event loop triggers this, and calls into libvirt, which then calls the
app's callback function ("f").
Is that right?
Yep, that's pretty much spot on.
In the remote case it's more tricky. What does the remote's
callback
function do when it gets an event? (This could happen pretty
asynchronously relative to other communications going on -- eg. in the
middle of a round of TLS chatter). Choices seem to be: (1) Send the
data OOB, unencrypted[1]. (2) Piggy-back the notification on to the
reply to the next call [not asynchronous]. (3) Try to work out where we
are in the TLS message and if necessary queue the event up and wait for
a "safe" place to insert the message in the protocol. (3) seems fairly
do-able.
The daemon has a buffer of outgoing data - and it appends to this buffer
discrete 'XDR' messages. So we should be able to simply append another
XDR message per notification & not have to overly worry about things
being mixed up in the stream. When the client is deserializing replies
during normal calls it'll have to keep an eye out for messages which are
in fact notifications, rather than its expected reply, but again that
should not be too hard since we're dealing with discrete XDR encoded
messages. So AFAICT we don't need any OOB or piggybacking stuff - just
queue up the data to send as normal.
[1] TLS 1.1 includes support for OOB data, but it's not really
clear if
GnuTLS supports that.
Yeah I get the impression that is fairly experimental stuff.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|