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

On 19.12.2013 16:15, Eric Blake wrote: > Several times in the past, qemu has implemented a new event, > but libvirt has not yet caught up to reporting that event to > the user applications. While it is possible to track libvirt > logs to see that an unknown event was received and ignored, > it would be nicer to copy what 'virsh qemu-monitor-command' > does, and expose this information to the end developer as > one of our unsupported qemu-specific commands. > > If you find yourself needing to use this API for more than > just development purposes, please ask on the libvirt list > for a supported counterpart event to be added in libvirt.so. > > While the supported virConnectDomainEventRegisterAny() API > takes an id which determines the signature of the callback, > this version takes a string filter and always uses the same > signature. Furthermore, I chose to expose this as a new API > instead of trying to add a new eventID at the top level, in > part because the generic option lacks event name filtering, > and in part because the normal domain event namespace should > not be polluted by a qemu-only event. I also added a flags > argument; unused for now, but we might decide to use it to > allow a user to request event names by glob or regex instead > of literal match. > > * include/libvirt/libvirt-qemu.h > (virConnectDomainQemuMonitorEventCallback) > (virConnectDomainQemuMonitorEventRegister) > (virConnectDomainQemuMonitorEventDeregister): New prototypes. > * src/libvirt-qemu.c (virConnectDomainQemuMonitorEventRegister) > (virConnectDomainQemuMonitorEventDeregister): New functions. > * src/libvirt_qemu.syms (LIBVIRT_QEMU_1.2.1): Export them. > * src/driver.h (virDrvConnectDomainQemuMonitorEventRegister) > (virDrvConnectDomainQemuMonitorEventDeregister): New callbacks. > > Signed-off-by: Eric Blake <eblake(a)redhat.com&gt; > --- > > Before I go and implement the guts of this new API, I first > wanted to get approval from the list that I'm on the right track. > > include/libvirt/libvirt-qemu.h | 31 ++++++++++- > src/driver.h | 15 +++++ > src/libvirt-qemu.c | 123 +++++++++++++++++++++++++++++++++++++++++ > src/libvirt_qemu.syms | 6 ++ > 4 files changed, 174 insertions(+), 1 deletion(-) > > diff --git a/include/libvirt/libvirt-qemu.h b/include/libvirt/libvirt-qemu.h > index 3e79a8c..5403093 100644 > --- a/include/libvirt/libvirt-qemu.h > +++ b/include/libvirt/libvirt-qemu.h > @@ -4,7 +4,7 @@ > * Description: Provides the interfaces of the libvirt library to handle > * qemu specific methods > * > - * Copyright (C) 2010, 2012 Red Hat, Inc. > + * Copyright (C) 2010, 2012-2013 Red Hat, Inc. > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -54,6 +54,35 @@ typedef enum { > char *virDomainQemuAgentCommand(virDomainPtr domain, const char *cmd, > int timeout, unsigned int flags); > > +/** > + * virConnectDomainQemuMonitorEventCallback: > + * @conn: the connection pointer > + * @dom: the domain pointer > + * @event: the name of the event > + * @details: the JSON details of the event > + * @opaque: application specified data > + * > + * The callback signature to use when registering for a qemu monitor > + * event with virConnectDomainQemuMonitorEventRegister(). > + */ > +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": ....}}"? 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.