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

[Jim Fehlig <jfehlig@suse.com>]

Ian Campbell wrote:
> 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)
>   

Yes, I did read it (again) :). And a later paragraph in the comment
explains bumping the version on the first incompatible change

* These guarantees apply only to stable releases of Xen. When an
* incompatible change is made in the unstable tree then
* LIBXL_API_VERSION will be bumped to the next expected stable
* release number on the first such change only.

which addresses my comment earlier in this thread about the version bump
being in a separate patch.

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

Yes, understood.

Regards,
Jim