Re: [libvirt] [PATCH 3/7] remote: use a separate connection for network APIs
On 03/28/2018 11:18 AM, Daniel P. Berrangé wrote:
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/remote/remote_daemon.h | 1 +
src/remote/remote_daemon_dispatch.c | 19 +++++++++++--------
src/rpc/gendispatch.pl | 6 ++++++
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/remote/remote_daemon.h b/src/remote/remote_daemon.h
index 31f433c15d..60be78fe0b 100644
--- a/src/remote/remote_daemon.h
+++ b/src/remote/remote_daemon.h
@@ -75,6 +75,7 @@ struct daemonClientPrivate {
*/
virConnectPtr conn;
virConnectPtr interfaceConn;
+ virConnectPtr networkConn;
daemonClientStreamPtr streams;
};
diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c
index 7971646c28..d0bc474850 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -1699,7 +1699,7 @@ remoteClientFreePrivateCallbacks(struct daemonClientPrivate *priv)
Trying to forward think - will there ever come a day when priv->conn ==
NULL, but priv->*Conn != NULL? The caller is gated on priv->conn...
IOW: Do we need to separate this one out a bit now
If not, then consider this
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
If so, then probably need to see adjustment...
John
DEREG_CB(priv->conn, priv->domainEventCallbacks,
priv->ndomainEventCallbacks,
virConnectDomainEventDeregisterAny, "domain");
- DEREG_CB(priv->conn, priv->networkEventCallbacks,
+ DEREG_CB(priv->networkConn, priv->networkEventCallbacks,
priv->nnetworkEventCallbacks,
virConnectNetworkEventDeregisterAny, "network");
DEREG_CB(priv->conn, priv->storageEventCallbacks,
[...]