[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable bisection] complete build-i386-libvirt

On lun, 2014-06-30 at 08:11 +0100, Ian Campbell wrote:
> On Sun, 2014-06-29 at 18:35 +0100, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job build-i386-libvirt
> > test libvirt-build
> > 
> > Tree: gnulib_libvirt 
> > git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]
> > Tree: libvirt git://xenbits.xen.org/libvirt.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen git://xenbits.xen.org/xen.git
> > 
> > *** Found and reproduced problem changeset ***
> > 
> >   Bug is in tree:  xen git://xenbits.xen.org/xen.git
> >   Bug introduced:  871b43a309d80ac99458c13c2c3da8d15c482d30
> >   Bug not present: 6cc89d3101d8874e01a69a89a65736a2adfbd199
> > 
> > 
> >   commit 871b43a309d80ac99458c13c2c3da8d15c482d30
> >   Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> >   Date:   Fri Jun 20 18:19:12 2014 +0200
> >   
> >       libxl: get and set soft affinity
> Dario,
> libvirt doesn't use the LIBXL_API_VERSION mechanism but instead uses the
> LIBXL_HAVE stuff to retain compatibility.
> Will you be able to send a patch against libvirt today to make it use
> the new interface (conditional on LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY)?
So, brief recap for the ones not knowing the details of this, libxl
interface for vcpu pinning is changing (basically,
libxl_set_vcpuaffinity() wants one more param).

Libxl provides some ifdefs for these situations, and in this case, the
gate to be used is, as Ian is saying:


One possible approach is to enclose all the calls into such
#ifdef-#endif but, although there are only two of them right now, I
don't like it (what if we need more calls in the future?).

I could come up with the alternatives attached to this message. In
patch1, I use the new interface in the code and #define it to the old
one if !LIBXL_HAV_VCPUINFO_SOFT_AFFINITY. In patch2 I do the opposite
(keep old interface in the code and redefine to new, with additional
param equal to NULL).

I like patch1 better, but I think it can cause "unused variable" like
warnings if, at some point in future, we will actually use the new soft
affinity parameter, when compiling on a version of libxl that does not
define HAVE_VCPUINFO_SOFT_AFFINITY, can't it? If yes, is it an issue? If
yes, a big enough one to make us prefer patch2?

Just let me know your thoughts, and I'll submit the one you prefer


PS. patches not tested, I'm updating my xen+libvirt testbox. Will be
able to test soon (for sure within today)

<<This happens because I choose it to happen!>> (Raistlin Majere)
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: patch1
Description: Text Data

Attachment: patch2
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.