[libvirt] [PATCH 3/7] remote: use a separate connection for network APIs

[John Ferlan]

On 03/28/2018 11:18 AM, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé <berrange at 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 at 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,
[...]