[PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Ian Campbell]

Upstream Xen is in the process of splitting the (stable API) xtl_*
interfaces out from the (unstable API) libxenctrl library and into a
new (stable API) libxentoollog.

In order to be compatible with Xen both before and after this
transition check for xtl_createlogger_stdiostream in a libxentoollog
library and use it if present. If it is not present assume it is in
libxenctrl.

Compile tested on Xen 4.6 and a development tree with the split in
place.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
I'm waiting on applying the upstream change until downstreams are
prepared for this. The latest upstream patch is
http://lists.xen.org/archives/html/xen-devel/2015-12/msg00454.html
which had to be reverted because I had somehow not properly checked if
libvirt used this interface
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01153.html

It might be nice to get this into 1.3.0 so that supports Xen 4.7 out
of the box? Not sure what the libvirt stable backport policy is but it
might also be good to eventually consider it for that?
---
 configure.ac | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 98cf210..b641cc7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -883,7 +883,6 @@ if test "$with_libxl" != "no" ; then
     PKG_CHECK_MODULES([LIBXL], [xenlight], [
      LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight`
      LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight`
-     LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
      with_libxl=yes
     ], [LIBXL_FOUND=no])
     if test "$LIBXL_FOUND" = "no"; then
@@ -896,7 +895,7 @@ if test "$with_libxl" != "no" ; then
         LIBS="$LIBS $LIBXL_LIBS"
         AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [
             with_libxl=yes
-            LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl"
+            LIBXL_LIBS="$LIBXL_LIBS -lxenlight"
         ],[
             if test "$with_libxl" = "yes"; then
                 fail=1
@@ -924,6 +923,14 @@ if test "$with_libxl" = "yes"; then
     if test "x$LIBXL_EXECBIN_DIR" != "x"; then
         AC_DEFINE_UNQUOTED([LIBXL_EXECBIN_DIR], ["$LIBXL_EXECBIN_DIR"], [directory containing Xen libexec binaries])
     fi
+    dnl Check if the xtl_* infrastructure is in libxentoollog
+    dnl (since Xen 4.7) if not then assume it is in libxenctrl
+    dnl (as it was for 4.6 and earler)
+    AC_CHECK_LIB([xentoollog], [xtl_createlogger_stdiostream], [
+        LIBXL_LIBS="$LIBXL_LIBS -lxentoollog"
+    ],[
+        LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
+    ])
 fi
 AM_CONDITIONAL([WITH_LIBXL], [test "$with_libxl" = "yes"])
 
-- 
2.1.4

Re: [libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Daniel P. Berrange]

On Thu, Dec 10, 2015 at 11:38:36AM +0000, Ian Campbell wrote:
> Upstream Xen is in the process of splitting the (stable API) xtl_*
> interfaces out from the (unstable API) libxenctrl library and into a
> new (stable API) libxentoollog.
> 
> In order to be compatible with Xen both before and after this
> transition check for xtl_createlogger_stdiostream in a libxentoollog
> library and use it if present. If it is not present assume it is in
> libxenctrl.

Ok, so there's no API changes, just move stuf from one to the other.

> It might be nice to get this into 1.3.0 so that supports Xen 4.7 out
> of the box? Not sure what the libvirt stable backport policy is but it
> might also be good to eventually consider it for that?

We've missed 1.3.0 release, but I'd be ok with adding it to the
stable branch if that's going to be useful.

> diff --git a/configure.ac b/configure.ac
> index 98cf210..b641cc7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -883,7 +883,6 @@ if test "$with_libxl" != "no" ; then
>      PKG_CHECK_MODULES([LIBXL], [xenlight], [
>       LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight`
>       LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight`
> -     LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
>       with_libxl=yes
>      ], [LIBXL_FOUND=no])
>      if test "$LIBXL_FOUND" = "no"; then
> @@ -896,7 +895,7 @@ if test "$with_libxl" != "no" ; then
>          LIBS="$LIBS $LIBXL_LIBS"
>          AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [
>              with_libxl=yes
> -            LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl"
> +            LIBXL_LIBS="$LIBXL_LIBS -lxenlight"
>          ],[
>              if test "$with_libxl" = "yes"; then
>                  fail=1
> @@ -924,6 +923,14 @@ if test "$with_libxl" = "yes"; then
>      if test "x$LIBXL_EXECBIN_DIR" != "x"; then
>          AC_DEFINE_UNQUOTED([LIBXL_EXECBIN_DIR], ["$LIBXL_EXECBIN_DIR"], [directory containing Xen libexec binaries])
>      fi
> +    dnl Check if the xtl_* infrastructure is in libxentoollog
> +    dnl (since Xen 4.7) if not then assume it is in libxenctrl
> +    dnl (as it was for 4.6 and earler)
> +    AC_CHECK_LIB([xentoollog], [xtl_createlogger_stdiostream], [
> +        LIBXL_LIBS="$LIBXL_LIBS -lxentoollog"
> +    ],[
> +        LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
> +    ])
>  fi
>  AM_CONDITIONAL([WITH_LIBXL], [test "$with_libxl" = "yes"])

Looks, fine from me but will let Jim push it.

Regards,
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 :|

Re: [libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Ian Campbell]

On Mon, 2015-12-14 at 11:15 +0000, Daniel P. Berrange wrote:
> On Thu, Dec 10, 2015 at 11:38:36AM +0000, Ian Campbell wrote:
> > Upstream Xen is in the process of splitting the (stable API) xtl_*
> > interfaces out from the (unstable API) libxenctrl library and into a
> > new (stable API) libxentoollog.
> > 
> > In order to be compatible with Xen both before and after this
> > transition check for xtl_createlogger_stdiostream in a libxentoollog
> > library and use it if present. If it is not present assume it is in
> > libxenctrl.
> 
> Ok, so there's no API changes, just move stuf from one to the other.

Indeed, it should really have been a separate library all along and the API
already setup that way.

I'm working on some other library splits, which will involve API changes,
but AFAIK they are all isolated from libvirt via the use of libxl, so there
should be no churn for you guys other than this one patch.

> > It might be nice to get this into 1.3.0 so that supports Xen 4.7 out
> > of the box? Not sure what the libvirt stable backport policy is but it
> > might also be good to eventually consider it for that?
> 
> We've missed 1.3.0 release, but I'd be ok with adding it to the
> stable branch if that's going to be useful.

I think it would, to allow things to build with Xen 4.7 (when it is
released).

[...]

> Looks, fine from me but will let Jim push it.

Thanks.

Re: [libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Jim Fehlig]

On 12/14/2015 04:37 AM, Ian Campbell wrote:
> On Mon, 2015-12-14 at 11:15 +0000, Daniel P. Berrange wrote:
>> On Thu, Dec 10, 2015 at 11:38:36AM +0000, Ian Campbell wrote:
>>> Upstream Xen is in the process of splitting the (stable API) xtl_*
>>> interfaces out from the (unstable API) libxenctrl library and into a
>>> new (stable API) libxentoollog.
>>>
>>> In order to be compatible with Xen both before and after this
>>> transition check for xtl_createlogger_stdiostream in a libxentoollog
>>> library and use it if present. If it is not present assume it is in
>>> libxenctrl.
>> Ok, so there's no API changes, just move stuf from one to the other.
> Indeed, it should really have been a separate library all along and the API
> already setup that way.
>
> I'm working on some other library splits, which will involve API changes,
> but AFAIK they are all isolated from libvirt via the use of libxl, so there
> should be no churn for you guys other than this one patch.
>
>>> It might be nice to get this into 1.3.0 so that supports Xen 4.7 out
>>> of the box? Not sure what the libvirt stable backport policy is but it
>>> might also be good to eventually consider it for that?
>> We've missed 1.3.0 release, but I'd be ok with adding it to the
>> stable branch if that's going to be useful.
> I think it would, to allow things to build with Xen 4.7 (when it is
> released).

I'm not sure it is necessary. libvirt is released monthly, so there will be
several releases before Xen 4.7 is released.

> [...]
>
>> Looks, fine from me but will let Jim push it.

I've pushed the patch to master, but not the 1.3.0 maint branch. It will be
included in the 1.3.1 release planned for mid January. Ian, do you think that is
sufficient?

Regards,
Jim

Re: [libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Ian Campbell]

On Tue, 2015-12-15 at 16:15 -0700, Jim Fehlig wrote:
> On 12/14/2015 04:37 AM, Ian Campbell wrote:
> > On Mon, 2015-12-14 at 11:15 +0000, Daniel P. Berrange wrote:
> > > On Thu, Dec 10, 2015 at 11:38:36AM +0000, Ian Campbell wrote:
> > > > Upstream Xen is in the process of splitting the (stable API) xtl_*
> > > > interfaces out from the (unstable API) libxenctrl library and into
> > > > a
> > > > new (stable API) libxentoollog.
> > > > 
> > > > In order to be compatible with Xen both before and after this
> > > > transition check for xtl_createlogger_stdiostream in a
> > > > libxentoollog
> > > > library and use it if present. If it is not present assume it is in
> > > > libxenctrl.
> > > Ok, so there's no API changes, just move stuf from one to the other.
> > Indeed, it should really have been a separate library all along and the
> > API
> > already setup that way.
> > 
> > I'm working on some other library splits, which will involve API
> > changes,
> > but AFAIK they are all isolated from libvirt via the use of libxl, so
> > there
> > should be no churn for you guys other than this one patch.
> > 
> > > > It might be nice to get this into 1.3.0 so that supports Xen 4.7
> > > > out
> > > > of the box? Not sure what the libvirt stable backport policy is but
> > > > it
> > > > might also be good to eventually consider it for that?
> > > We've missed 1.3.0 release, but I'd be ok with adding it to the
> > > stable branch if that's going to be useful.
> > I think it would, to allow things to build with Xen 4.7 (when it is
> > released).
> 
> I'm not sure it is necessary. libvirt is released monthly, so there will be
> several releases before Xen 4.7 is released.

AH, I didn't realise it was on such a fast cadence, that's ok then.

> > [...]
> > 
> > > Looks, fine from me but will let Jim push it.
> 
> I've pushed the patch to master, but not the 1.3.0 maint branch. It will be
> included in the 1.3.1 release planned for mid January. Ian, do you think that is
> sufficient?

Easily, thanks.

Ian.