xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
@ 2016-04-05 11:39 Wei Liu
  0 siblings, 0 replies; 9+ messages in thread
From: Wei Liu @ 2016-04-05 11:39 UTC (permalink / raw)
  To: libvir-list; +Cc: Xen-devel, Jim Fehlig, Wei Liu, Ian Jackson

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
  2016-04-14 17:59         ` Ian Jackson
  2016-04-14 18:05           ` Dario Faggioli
@ 2016-04-15  9:14           ` Olaf Hering
  1 sibling, 0 replies; 9+ messages in thread
From: Olaf Hering @ 2016-04-15  9:14 UTC (permalink / raw)
  To: Ian Jackson
  Cc: Wei Liu, LibVirt Development List, Dario Faggioli, George Dunlap,
	Jim Fehlig, Xen-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
  2016-04-14 17:59         ` Ian Jackson
@ 2016-04-14 18:05           ` Dario Faggioli
  2016-04-15  9:14           ` Olaf Hering
  1 sibling, 0 replies; 9+ messages in thread
From: Dario Faggioli @ 2016-04-14 18:05 UTC (permalink / raw)
  To: Ian Jackson
  Cc: LibVirt Development List, Xen-devel, Jim Fehlig, Wei Liu, George Dunlap


[-- Attachment #1.1: Type: text/plain, Size: 1041 bytes --]

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
-- 
<<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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
       [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
  0 siblings, 2 replies; 9+ messages in thread
From: Ian Jackson @ 2016-04-14 17:59 UTC (permalink / raw)
  To: Dario Faggioli
  Cc: LibVirt Development List, Xen-devel, Jim Fehlig, Wei Liu, George Dunlap

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
       [not found]     ` <570ED6B4.3060102@suse.com>
@ 2016-04-14  7:40       ` Dario Faggioli
       [not found]       ` <1460619652.13871.130.camel@citrix.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Dario Faggioli @ 2016-04-14  7:40 UTC (permalink / raw)
  To: Jim Fehlig, George Dunlap
  Cc: LibVirt Development List, Xen-devel, Wei Liu, Ian Jackson


[-- Attachment #1.1: Type: text/plain, Size: 1054 bytes --]

On Wed, 2016-04-13 at 17:31 -0600, Jim Fehlig wrote:
> > On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig <jfehlig@suse.com>
> > 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
-- 
<<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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
  2016-04-13  9:09   ` George Dunlap
@ 2016-04-13 23:31     ` Jim Fehlig
       [not found]     ` <570ED6B4.3060102@suse.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Jim Fehlig @ 2016-04-13 23:31 UTC (permalink / raw)
  To: George Dunlap; +Cc: LibVirt Development List, Xen-devel, Wei Liu, Ian Jackson

On 04/13/2016 03:09 AM, 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.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
       [not found] ` <570D6942.8020106@suse.com>
  2016-04-12 22:06   ` Wei Liu
@ 2016-04-13  9:09   ` George Dunlap
  2016-04-13 23:31     ` Jim Fehlig
       [not found]     ` <570ED6B4.3060102@suse.com>
  1 sibling, 2 replies; 9+ messages in thread
From: George Dunlap @ 2016-04-13  9:09 UTC (permalink / raw)
  To: Jim Fehlig; +Cc: LibVirt Development List, Xen-devel, Wei Liu, Ian Jackson

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.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
       [not found] ` <570D6942.8020106@suse.com>
@ 2016-04-12 22:06   ` Wei Liu
  2016-04-13  9:09   ` George Dunlap
  1 sibling, 0 replies; 9+ messages in thread
From: Wei Liu @ 2016-04-12 22:06 UTC (permalink / raw)
  To: Jim Fehlig; +Cc: libvir-list, Xen-devel, Wei Liu, Ian Jackson

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?
       [not found] <20160405113936.GA18120@citrix.com>
@ 2016-04-12 21:31 ` Jim Fehlig
       [not found] ` <570D6942.8020106@suse.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Jim Fehlig @ 2016-04-12 21:31 UTC (permalink / raw)
  To: Wei Liu; +Cc: libvir-list, Xen-devel, Ian Jackson

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2016-04-15  9:14 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-05 11:39 Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION? Wei Liu
     [not found] <20160405113936.GA18120@citrix.com>
2016-04-12 21:31 ` 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 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

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).