Re: [libvirt] [PATCH 08/10] Add test case for loading driver modules
On Mon, May 21, 2012 at 09:56:19PM -0600, Eric Blake wrote:
On 05/21/2012 01:59 PM, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange(a)redhat.com>
>
> To ensure all symbols used by loadable driver modules are
> exported in libvirt.so, add a test suite that simply loads
> each driver in turn
>
> * tests/Makefile.am, tests/virdrivermoduletest.c: Add
> a test case for loading drivers
>
> Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
> ---
> tests/Makefile.am | 11 +++++
> tests/virdrivermoduletest.c | 104 +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 115 insertions(+), 0 deletions(-)
> create mode 100644 tests/virdrivermoduletest.c
ACK.
> +static int testDriverModule(const void *args)
> +{
> + const struct testDriverData *data = args;
> +
> + if (data->dep1 &&
> + !virDriverLoadModule(data->dep1))
> + return -1;
> +
> + if (!virDriverLoadModule(data->name))
> + return -1;
> +
> + return 0;
> +}
Any reason why we don't have a virDriverUnloadModule?
Unloading dynamic libraries can trigger a world of hurt in threaded
applications which use thread locals. eg this previous fix:
commit 8e44e5593eb9b89fbc0b54fde15f130707a0d81e
Author: Daniel P. Berrange <berrange(a)redhat.com>
Date: Thu Sep 1 17:57:06 2011 +0100
Prevent crash from dlclose() of libvirt.so
When libvirt calls virInitialize it creates a thread local
for the virErrorPtr storage, and registers a callback to
cleanup memory when a thread exits. When libvirt is dlclose()d
or otherwise made non-resident, the callback function is
removed from memory, but the thread local may still exist
and if a thread later exists, it will invoke the callback
and SEGV. There may also be other thread locals with callbacks
pointing to libvirt code, so it is in general never safe to
unload libvirt.so from memory once initialized.
To allow dlclose() to succeed, but keep libvirt.so resident
in memory, link with '-z nodelete'. This issue was first
found with the libvirt CIM provider, but can potentially
hit many of the dynamic language bindings which all ultimately
involve dlopen() in some way, either on libvirt.so itself,
or on the glue code for the binding which in turns links
to libvirt
while this applied to libvirt.so used by client applcations,
IMHO, the same problem exists wrt to libvirtd & loadable
driver modules.
Since I see no compelling reason to unload modules, it is safer
to just not support it.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|