Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
On Thu, Apr 14, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] Fixing libvirt's libxl driver
> breakage -- where to define LIBXL_API_VERSION?"):
> > And, in those cases, usage should be gated by the appropriate
> > LIBXL_HAVE_FOOBAR symbol, which I see in the sources (e.g.,
> > for LIBXL_HAVE_NO_SUSPEND_RESUME or LIBXL_HAVE_DOMAIN_NODEAFFINITY) to
> > be the case, so good again. :-)
>
> If libvirt specifies LIBXL_API_VERSION then it does not need to check
> any LIBXL_HAVE_*, since it will actually get an API corresponding to
> the specified API_VERSION.
This cant be true, because otherwise it will be unable to use vscsi and
perhaps usb (and whatever else showed up after 4.2).
Does that also mean that for example things related to LIBXL_HAVE_VSCSI
need to be wrapped in "#if LIBXL_API_VERSION > $whatever"? Maybe I'm
just misunderstand what you are trying to say.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
On Thu, 2016-04-14 at 18:59 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] Fixing libvirt's libxl driver
> breakage -- where to define LIBXL_API_VERSION?"):
> >
> > And, in those cases, usage should be gated by the appropriate
> > LIBXL_HAVE_FOOBAR symbol, which I see in the sources (e.g.,
> > for LIBXL_HAVE_NO_SUSPEND_RESUME or LIBXL_HAVE_DOMAIN_NODEAFFINITY)
> > to
> > be the case, so good again. :-)
> If libvirt specifies LIBXL_API_VERSION then it does not need to check
> any LIBXL_HAVE_*, since it will actually get an API corresponding to
> the specified API_VERSION.
>
I concur. And in fact, this patch introduces an LIBXL_API_VERSION and
drops the use of LIBXL_HAVE_*.
And I think the patch is right. :-)
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
Dario Faggioli writes ("Re: [Xen-devel] Fixing libvirt's libxl driver breakage
-- where to define LIBXL_API_VERSION?"):
> And, in those cases, usage should be gated by the appropriate
> LIBXL_HAVE_FOOBAR symbol, which I see in the sources (e.g.,
> for LIBXL_HAVE_NO_SUSPEND_RESUME or LIBXL_HAVE_DOMAIN_NODEAFFINITY) to
> be the case, so good again. :-)
If libvirt specifies LIBXL_API_VERSION then it does not need to check
any LIBXL_HAVE_*, since it will actually get an API corresponding to
the specified API_VERSION.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
On Wed, 2016-04-13 at 17:31 -0600, Jim Fehlig wrote: > > On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig > > wrote: > > > > I'll knock up a patch to set the LIBXL_API_VERSION to 0x040200. The > only APIs > that have changed since 0x040200 are libxl_set_vcpuaffinity and > libxl_domain_create_restore, but libvirt does not use the changes > (added > params). > I think this is a good choice. > libvirt does use new libxl APIs added since Xen 4.2, but those aren't > tied to a specific LIBXL_API_VERSION. > And, in those cases, usage should be gated by the appropriate LIBXL_HAVE_FOOBAR symbol, which I see in the sources (e.g., for LIBXL_HAVE_NO_SUSPEND_RESUME or LIBXL_HAVE_DOMAIN_NODEAFFINITY) to be the case, so good again. :-) Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
On 04/13/2016 03:09 AM, George Dunlap wrote: > On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig wrote: >> Wei Liu wrote: >>> Hi libvirt maintainers, >> Sorry for the delay. Slowly catching up on mail after vacation... >> >>> Xen's control library libxenlight (libxl) requires application >>> (libvirt in this case) to explictily define LIBXL_API_VERSION. >> Where is this requirement written? :-) >> >>> This is >>> lacking at the moment so libvirt's libxl driver always gets the latest >>> APIs. >> IMO, that is what we want for upstream libvirt. Downstreams can choose a >> specific version if they want. > I think one of us isn't understanding the situation properly. Is it > not the case that currently, all releases of libvirt *will not > compile* against Xen 4.7 once it's released? So people downloading > and building libvirt will have to either 1) root around and try to > figure out what version of Xen it will build against, 2) manually add > in a #define *with the correct API version* to a header somewhere to > make it build properly, or 3) update to a version of libvirt that > supports the new api (which at the moment hasn't even been released > yet)? > > All of those options are completely unacceptable. Older versions of > libvirt should Just Work when compiled against newer versions of Xen. Yes, agreed. In practice though folks want a new libvirt with the new Xen, which is probably why no one has complained thus far. I'll knock up a patch to set the LIBXL_API_VERSION to 0x040200. The only APIs that have changed since 0x040200 are libxl_set_vcpuaffinity and libxl_domain_create_restore, but libvirt does not use the changes (added params). libvirt does use new libxl APIs added since Xen 4.2, but those aren't tied to a specific LIBXL_API_VERSION. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig wrote: > Wei Liu wrote: >> Hi libvirt maintainers, > > Sorry for the delay. Slowly catching up on mail after vacation... > >> >> Xen's control library libxenlight (libxl) requires application >> (libvirt in this case) to explictily define LIBXL_API_VERSION. > > Where is this requirement written? :-) > >> This is >> lacking at the moment so libvirt's libxl driver always gets the latest >> APIs. > > IMO, that is what we want for upstream libvirt. Downstreams can choose a > specific version if they want. I think one of us isn't understanding the situation properly. Is it not the case that currently, all releases of libvirt *will not compile* against Xen 4.7 once it's released? So people downloading and building libvirt will have to either 1) root around and try to figure out what version of Xen it will build against, 2) manually add in a #define *with the correct API version* to a header somewhere to make it build properly, or 3) update to a version of libvirt that supports the new api (which at the moment hasn't even been released yet)? All of those options are completely unacceptable. Older versions of libvirt should Just Work when compiled against newer versions of Xen. I think it does make sense to have the libvirt development branch not specify an API version; but when it branches for release, it should set LIBXL_API_VERSION to whatever the current version is at the time of the branch. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
On Tue, Apr 12, 2016 at 03:31:46PM -0600, Jim Fehlig wrote: > Wei Liu wrote: > > Hi libvirt maintainers, > > Sorry for the delay. Slowly catching up on mail after vacation... > > > > > Xen's control library libxenlight (libxl) requires application > > (libvirt in this case) to explictily define LIBXL_API_VERSION. > > Where is this requirement written? :-) > > > This is > > lacking at the moment so libvirt's libxl driver always gets the latest > > APIs. > > IMO, that is what we want for upstream libvirt. Downstreams can choose a > specific version if they want. > > > We changed one of the APIs in libxl so libvirt's libxl driver > > can't build at the moment. > > A quick glance ahead in my libvirt mail tells me you fixed this with the > preferred LIBXL_HAVE_* pattern. > It's already done that way. :-) Wei. > Regards, > Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
Wei Liu wrote: > Hi libvirt maintainers, Sorry for the delay. Slowly catching up on mail after vacation... > > Xen's control library libxenlight (libxl) requires application > (libvirt in this case) to explictily define LIBXL_API_VERSION. Where is this requirement written? :-) > This is > lacking at the moment so libvirt's libxl driver always gets the latest > APIs. IMO, that is what we want for upstream libvirt. Downstreams can choose a specific version if they want. > We changed one of the APIs in libxl so libvirt's libxl driver > can't build at the moment. A quick glance ahead in my libvirt mail tells me you fixed this with the preferred LIBXL_HAVE_* pattern. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
Hi libvirt maintainers, Xen's control library libxenlight (libxl) requires application (libvirt in this case) to explictily define LIBXL_API_VERSION. This is lacking at the moment so libvirt's libxl driver always gets the latest APIs. We changed one of the APIs in libxl so libvirt's libxl driver can't build at the moment. I want to submit a patch for libvirt to define LIBXL_API_VERSION, but I'm not sure where I should add that to. Can you give me some pointers? Or even better -- a specific file that I should edit? src/Makefile.am and src/Makfile.in are good candicate to me as far as I can tell. Thanks Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
