[libvirt] [PATCH 00/20] Fix virConnect(Un)RegisterCloseCallback and get rid of global variables

John Ferlan jferlan at redhat.com
Thu Mar 15 21:07:07 UTC 2018



On 03/08/2018 07:20 AM, Marc Hartmayer wrote:
> The first part of this patch series fixes the behavior of
> virConnectSupportsFeatures, virConnect(Un)RegisterCloseCallback, and
> implements these features in the test driver. This results in a better
> code coverage of our test suite.
> 
> The subsequent patches remove the need to have the global variables
> 'qemuProgram', 'adminProgram', 'lxcProgram, and 'remoteProgram' in
> remote_daemon.[ch]. They only work in combination with the fixed
> behavior of virConnectSupportsFeatures and
> virConnect(Un)RegisterCloseCallback.
> 
> Marc Hartmayer (20):
>   driver: Add typedef for the anonymous enum used for driver features
>   remote: Don't hard code the feature
>     VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK as available
>   virConnect(Un)RegisterCloseCallback: Throw an error in case the API is
>     not supported
>   test: Implement virConnectSupportsFeature
>   test: Implement virConnect(Un)RegisterCloseCallback
>   test: testOpenDefault: introduce cleanup path
>   test: testOpenFromFile: return VIR_DRV_OPEN_SUCCESS in case of success
>   test: testConnectAuthenticate: Take the lock when accessing mutable
>     values
>   test: testConnectClose: Set privateData to NULL in all cases
>   test: rename defaultConn to defaultPrivconn
>   test: introduce testDriverCloseInternal
>   test: fix error path in testConnectOpen
>   test: Convert testDriver to virObjectLockable
>   remote: remove unneeded global variables
>   stream: Access stream->prog instead of a hard-coded global variable
>   remote: Set eventID explicitly to an invalid value
>   remote: Add the information which program has to be used to
>     daemonClientEventCallback
>   remote: Use domainClientEventCallbacks for
>     remoteReplayConnectionClosedEvent
>   rpc: Introduce virNetServerGetProgramLocked helper function
>   remote/rpc: Use virNetServerGetProgram() to determine the program
> 
>  src/esx/esx_driver.c                |  18 +-
>  src/libvirt-host.c                  |  24 +--
>  src/libvirt_internal.h              |   4 +-
>  src/libvirt_remote.syms             |   1 +
>  src/libxl/libxl_driver.c            |  13 +-
>  src/lxc/lxc_driver.c                |  24 ++-
>  src/openvz/openvz_driver.c          |  15 +-
>  src/qemu/qemu_driver.c              |   8 +-
>  src/remote/remote_daemon.c          |   8 +-
>  src/remote/remote_daemon.h          |   3 -
>  src/remote/remote_daemon_dispatch.c | 182 +++++++++++--------
>  src/remote/remote_daemon_stream.c   |  14 +-
>  src/rpc/gendispatch.pl              |   2 +
>  src/rpc/virnetserver.c              |  54 +++++-
>  src/rpc/virnetserver.h              |   2 +
>  src/test/test_driver.c              | 339 ++++++++++++++++++++++--------------
>  src/vz/vz_driver.c                  |  15 +-
>  src/xen/xen_driver.c                |  15 +-
>  tools/virsh.c                       |  11 +-
>  19 files changed, 504 insertions(+), 248 deletions(-)
> 

So based on what I R-B'd - I can grab patches 1, 6 -> 12, and 14 -> 16
alter the couple of minor things noted, then push...

FWIW: patch 13 depends on a couple of things changed in patch 5, so
while it is fine, I'd rather not get too many merge conflicts. There is
one minor one from

I'll also keep defaultPrivconn and not change to defaultPrivateData as
that just gets way too messy. I agree since we have privconn in general,
it'll be fine for the global too...

That should help reduce the v2 pile a bit!

John




More information about the libvir-list mailing list