Re: [Xen-devel] [PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.11.14 at 13:08, <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
>> >>> On 04.11.14 at 12:50, <andrew.cooper3@xxxxxxxxxx> 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.

For __XEN_INTERFACE_VERSION__ - yes. But
__XEN_LATEST_INTERFACE_VERSION__ mainly announces
the version and is used to set the former if otherwise unset.

Jan


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