Re: [libvirt] [RFC PATCH] qemu: new API for tracking arbitrary monitor events

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'?