On 19.12.2013 21:36, Eric Blake wrote:
> 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'?
Well, in qemu code base it seems like they're using struct timeval; but
typecasting into int64_t both seconds and microseconds. So I'd say it's
fine for us to go with ULL seconds, uint microseconds. Although I'm not
that convinced that we should stick with unsigned, signed type will work
too. At least for another ~25 years on my RPi :)
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list