From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH] libxl: unconst the event argument to the event_occurs hook. Date: Tue, 30 Apr 2013 16:47:58 -0600 Message-ID: <51804A1E.8030700@suse.com> References: <1366976544-3428-1-git-send-email-ian.campbell@citrix.com> <517AF031.4070004@suse.com> <1367223373.3142.189.camel@zakaz.uk.xensource.com> <517F477B.6090503@suse.com> <1367315020.3142.460.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1367315020.3142.460.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "George.Dunlap@citix.com" , Ian Jackson , Rob Hoes , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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