[libvirt] [PATCH 06/10] Qemu Monitor API entry point.

Eric Blake eblake at redhat.com
Wed Apr 21 17:41:04 UTC 2010


On 04/21/2010 10:01 AM, Chris Lalancette wrote:
> Add the library entry point for the new virDomainQemuMonitorCommand()
> entry point.  Because this is not part of the "normal" libvirt API,
> it gets it's own header file, library file, and will eventually
> get it's own over-the-wire protocol later in the series.

Now we get into the realm of multiple .so in a single package, at which
point switching over to the libtool versioning scheme makes more sense.
 In other words, it is now _very_ feasible that libvirt.so will change
versions between libvirt 0.8.1 and 0.8.2, while libvirt-qemu.so stays
stable between those two package releases.

We need to revisit this thread:
https://www.redhat.com/archives/libvir-list/2010-April/msg00226.html

> +++ b/src/Makefile.am
> @@ -32,7 +32,7 @@ if WITH_NETWORK
>  UUID=$(shell uuidgen 2>/dev/null)
>  endif
>  
> -lib_LTLIBRARIES = libvirt.la
> +lib_LTLIBRARIES = libvirt.la libvirt-qemu.la
>  
>  moddir = $(libdir)/libvirt/drivers
>  mod_LTLIBRARIES =
> @@ -947,6 +947,12 @@ libvirt_test_la_LIBADD = $(libvirt_la_LIBADD)
>  libvirt_test_la_LDFLAGS = $(test_LDFLAGS)
>  libvirt_test_la_CFLAGS = $(COVERAGE_CFLAGS)
>  
> +libvirt_qemu_la_SOURCES = libvirt-qemu.c
> +libvirt_qemu_la_LDFLAGS = $(CYGWIN_EXTRA_LDFLAGS) $(MINGW_EXTRA_LDFLAGS)

Shouldn't there be a -version-info $(...) as part of the LDFLAGS, since
this is a public rather than a convenience library?  Which gets back to
the question of whether $(LIBVIRT_VERSION_INFO) is the right thing to use.

> +libvirt_qemu_la_CFLAGS = $(COVERAGE_CFLAGS)
> +libvirt_qemu_la_LIBADD = libvirt_util.la libvirt_driver_qemu.la \
> +			libvirt_driver_remote.la $(CYGWIN_EXTRA_LIBADD) \
> +			../gnulib/lib/libgnu.la

I still haven't had a successful attempt of building libvirt on cygwin;
I'm wondering if we have some cruft with all that
$(CYGWIN_EXTRA_LDFLAGS), but that is independent of this patch.

> +
> +int
> +virDomainQemuMonitorCommand(virDomainPtr domain, const char *cmd,
> +                            char **result, unsigned int flags)
> +{
> +    virConnectPtr conn;
> +
> +    DEBUG("domain=%p, cmd=%s, result=%p, flags=%u", domain, cmd, result, flags);

Should we add a use of virCheckFlags here, to reject unknown flags?

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100421/8636c468/attachment-0001.sig>


More information about the libvir-list mailing list