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
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
