On 12/19/2013 09:01 AM, Daniel P. Berrange wrote:
>>> +typedef void (*virConnectDomainQemuMonitorEventCallback)(virConnectPtr conn,
>>> + virDomainPtr dom,
>>> + const char *event,
>>> + const char *details,
>>> + void *opaque);
>>
>>
>> So for instance on this event:
>> 2013-12-19 15:55:05.575+0000: 18630: debug : qemuMonitorJSONIOProcessLine:172 : QEMU_MONITOR_RECV_EVENT: mon=0x7f8c80008910 event={"timestamp": {"seconds": 1387468505, "microseconds": 574652}, "event": "SPICE_INITIALIZED", "data": {"server": {"auth": "none", "port": "5900", "family": "ipv4", "host": "127.0.0.1"}, "client": {"port": "39285", "family": "ipv4", "channel-type": 4, "connection-id": 375558326, "host": "127.0.0.1", "channel-id": 0, "tls": false}}}
>>
>> the callback will be invoked with:
>> event="SPICE_INITIALIZED"
>> details="{"server": {"auth": ....}}"?
>
Ooh, just noticed that the timestamp is not part of the event data;
probably worth adding another parameter to the callback function to list
the event timestamp (as knowing when qemu fired an event may indeed be
important to a developer using this interface for debugging). What type
would be best? Is it okay to tie our public interface to struct
timespec (which in turn risks problems if a compile-time switch can move
between 32- and 64-bit seconds since Epoch), or should I just open-code
it to two parameters: 'long long seconds, int microseconds'?
>
>> After all, I don't think we should do anything clever about it. Apps dealing with monitor/agent code (e.g. command passthru) are dealing with JSON anyway.
>
> Agreed, just sending out the JSON 'data' block as-is seems fine to me.
Sounds like I'm on the right track, then.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list