From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: __XEN_LATEST_INTERFACE_VERSION__ is still 0x00040600 in staging Date: Mon, 14 Sep 2015 15:19:51 +0300 Message-ID: <55F6BB67.2070201@bitdefender.com> References: <55F6B53D.6050803@bitdefender.com> <55F6D5F102000078000A2911@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55F6D5F102000078000A2911@prv-mh.provo.novell.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: Jan Beulich Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 09/14/2015 03:13 PM, Jan Beulich wrote: >>>> On 14.09.15 at 13:53, wrote: >> I've found this out by accident, since I have some code that does some >> #ifdef tricks based on __XEN_LATEST_INTERFACE_VERSION__, but while >> running staging ("Xen version 4.7-unstable") it seems that in >> xen/xen-compat.h we still have: >> >> #define __XEN_LATEST_INTERFACE_VERSION__ 0x00040600 >> >> Is this intended? > > Was there any incompatible interface change already that would > have required bumping the value? None, at least as far as my code is concerned. It's just that I've already added a new libxc helper function with assorted HV-side code and just assumed that __XEN_LATEST_INTERFACE_VERSION__ had been bumped to 0x00040700, so some of my own code wasn't being compiled as it depended on that value. Of course, there's nothing wrong with the current approach, I was just curious if bumps happen as soon as a new version is out or only when the interface changes. Thanks, Razvan