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'?
> 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
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)