From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH v2 for-4.5] xen: Bump Xen interface for
	Xen-4.5
Date: Tue, 4 Nov 2014 12:08:50 +0000
Message-ID: <1415102930.11486.40.camel@citrix.com>
References: <5458BCA9.3000304@citrix.com>
	<1415101802-24096-1-git-send-email-andrew.cooper3@citrix.com>
	<5458CDF70200007800044C30@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5458CDF70200007800044C30@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
> >>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
> > c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> > structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> > API.
> > 
> > While these were toolstack hypercalls and documented as liable to change in
> > the future, it causes build issues for certain tools (valgrind, strace).
> > 
> > As HVM ops have no specific interface version, the main Xen interface 
> > version
> > needs to be bumped to compensate.
> 
> Content-wise I don't really object to this patch, but I view it as
> merely cosmetic rather than fixing anything: Tool stack interfaces
> are declared to be volatile just because we want to avoid exactly
> this need for bumping versions or anything when altering or
> dropping them. If there are out of tree consumers of them, it is
> their responsibility to keep up with our changes (or have their
> own clones of the canonical headers).
> 
> Also we didn't bother incrementing the version just because of a
> release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
> shared interface versions, yet especially in the case of 4.1 I'm
> pretty certain even without explicitly checking that there were
> tool stack interface changes.

I always thought __XEN_(LATEST_)INTERFACE_VERSION__ were more to do with
API rather than ABI, i.e. it gets used to revert
__HYPERVISOR_sched_op_compat into providing __HYPERVISOR_sched_op for
older consumers and things like that.

Ian.