Re: [Xen-devel] [PATCH] libxl: unconst the event argument to the event_occurs hook.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-04-30 at 05:24 +0100, Jim Fehlig wrote:
> > Looking at this again today this happens to be true if LIBXL_API_VERSION
> > is undefined but I wonder if we ought to explicitly define
> > LIBXL_API_VERSION to 0xffffff if the user doesn't supply it?
> >   
> 
> Ah, good point.  But setting LIBXL_API_VERSION to 0xffffffff if the app
> doesn't supply it means the app, which e.g. built fine on 4.2, would no
> longer compile on 4.3 right?

Yes, this is the same as if LIBXL_API_VERSION remains undefined though,
an app which doesn't ask for a specific version automatically gets the
latest version.

>From libxl.h:

 * In order to make such compatibility possible it is required that
 * application which want to be exposed to a particular API #define
 * LIBXL_API_VERSION before including libxl.h or any other libxl
 * header. The syntax of the LIBXL_API_VERSION is:
 *    0xVVSSEE
 * where ($(XEN_xxx) from xen/Makefile):
 *   VV is the Xen major release number, $(XEN_VERSION)
 *   SS is the Xen sub version number, $(XEN_SUBVERSION)
 *   EE is the Xen extra version digit, first numeric part of
 *     $(XEN_EXTRAVERSION) not including the leading "."
 * For example the first stable API version, supported by Xen 4.2.0,
 * is 0x040200.
 *
 * Lack of LIBXL_API_VERSION means "the latest" which will
 * change. Specifying an unknown LIBXL_API_VERSION will result in a
 * compile time error.
(the whole comment is probably worth a read)

If you are concerned about supporting 4.2 onwards then you need to
#define LIBXL_API_VERSION to 0x040200.

Ian.


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