From: George Dunlap <george.dunlap@citrix.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: LibVirt Development List <libvir-list@redhat.com>,
Xen-devel <xen-devel@lists.xenproject.org>,
Jim Fehlig <jfehlig@suse.com>, Wei Liu <wei.liu2@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [libvirt] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
Date: Wed, 13 Apr 2016 10:50:01 +0100 [thread overview]
Message-ID: <570E1649.30902__33948.7851052128$1460541087$gmane$org@citrix.com> (raw)
In-Reply-To: <20160413092654.GE8847@redhat.com>
On 13/04/16 10:26, Daniel P. Berrange wrote:
> On Wed, Apr 13, 2016 at 10:09:16AM +0100, George Dunlap wrote:
>> On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig <jfehlig@suse.com> 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.
>
> FYI, libvirt doesn't do branching for releases - we always just cut the
> release straight from the master branch. We only actually create branches
> on demand, when we find we want to backport fixes to a previous release.
>
> Does libvirt master really need to always use the latest API version ?
>
> It feels like libvirt could just set LIBXL_API_VERSION to the lowest
> version it requires in order to get the functionality we know we are
> able to currently build against. IOW, we'd only need to update the
> define for LIBXL_API_VERSION when we merge patches that actually need
> the newer functionality.
Oh, right -- yes, if that's the libvirt development model then it makes
more sense to do what works best with that model to make sure each
release has an appropriate LIBXL_API_VERSION.
On reflection, it's probably a better idea even from a Xen development
perspective. I was originally thinking that it would be nice to have
the testing automatically flag up an update in libxl that could use a
corresponding update in libvirt. But in practice, since we use these
tests as a push-gate, having changesets in the xen development branch
which break against libvirt master but require changes in libvirt master
to fix is actually causes a fair amount of hassle.
It might be useful for the XenProject to have a non-pushgate test which
tests libvirt without a LIBXL_API_VERSION, just to flag things up, but
that's something we can sort out on our side with a sed script.
Thanks,
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-13 9:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160405113936.GA18120@citrix.com>
2016-04-12 21:31 ` Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION? Jim Fehlig
[not found] ` <570D6942.8020106@suse.com>
2016-04-12 22:06 ` Wei Liu
2016-04-13 9:09 ` George Dunlap
2016-04-13 9:26 ` [libvirt] " Daniel P. Berrange
[not found] ` <20160413092654.GE8847@redhat.com>
2016-04-13 9:50 ` George Dunlap [this message]
2016-04-13 13:28 ` Wei Liu
2016-04-13 23:44 ` Jim Fehlig
[not found] ` <570ED9DF.5070606@suse.com>
2016-06-27 15:33 ` Ian Jackson
2016-06-27 15:54 ` Ian Jackson
2016-06-27 16:03 ` Daniel P. Berrange
2016-06-27 16:12 ` Ian Jackson
2016-06-27 16:17 ` Daniel P. Berrange
2016-06-27 16:35 ` Jim Fehlig
2016-06-27 16:54 ` Ian Jackson
2016-06-28 7:01 ` Jan Beulich
2016-06-28 10:42 ` Ian Jackson
2016-04-13 23:31 ` Jim Fehlig
[not found] ` <570ED6B4.3060102@suse.com>
2016-04-14 7:40 ` Dario Faggioli
[not found] ` <1460619652.13871.130.camel@citrix.com>
2016-04-14 17:59 ` Ian Jackson
2016-04-14 18:05 ` Dario Faggioli
2016-04-15 9:14 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='570E1649.30902__33948.7851052128$1460541087$gmane$org@citrix.com' \
--to=george.dunlap@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=berrange@redhat.com \
--cc=jfehlig@suse.com \
--cc=libvir-list@redhat.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).