Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages]

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"):
> Ian: I did take the liberty to backport Anthony's
> 
> 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype

Thanks.

> Beyond this I'd like the following to be considered:
> 
> 6409210a5f51 libxencall: osdep_hypercall() should return long
> bef64f2c0019 libxencall: introduce variant of xencall2() returning long
> 01a2d001dea2 libxencall: Bump SONAME following new functionality
> 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris)

I agree these are needed.

Don't we need these, or something like them in 4.14 and earlier too ?

> If those are to be taken (which means in particular if the question of
> the .so versioning can be properly sorted),
> 
> 198a2bc6f149 x86/HVM: wire up multicalls
> 
> is going to be required as a prereq. I have backports of all of the
> above ready (so I could put them in if you tell me to), but for
> 01a2d001dea2 only in its straightforward but simplistic form, which I'm
> not sure is the right thing to do.

So, I have queued 198a2bc6f149 too.

As for the ABI: 01a2d001dea2 introduces VERS_1.3 with xencall2L.
I think backporting it to 4.15 means declaring that that is precisely
what VERS_1.3 is, and that any future changes must be in VERS_1.4.

I checked that after the backport of 198a2bc6f149, the two files
defining VERS_1.3 are the same.  Well, they are different because of
  7ffbed8681a0
  libxencall: drop bogus mentioning of xencall6()
which is fine, since that symbol didn't exist in any version.

So I propose to bump xencall to 1.4 in staging, to make sure we don't
break the ABI for 1.3 by mistake.

Andrew Cooper writes ("Re: preparations for 4.15.1 and 4.13.4"):
> We can backport changes in SONAME safely so long as:
> 
> 1) We declare VERS_1.2 to be fixed and released.  This means that we
> bump to 1.3 for the next change, even if it is ahead of Xen 4.16 being
> release, and
> 
> 2) *All* ABI changes up to VERS_1.2 are backported.

I think this is what I am doing, except that I think Andy wrote "1.2"
instead of "1.3".  "1.2" is currently in staging-4.15, without my
queued series.

> The ABI called VERS_1.2 must be identical on all older branches to avoid
> binary problems when rebuilding a package against old-xen+updates, and
> then updating to a newer Xen.

Indeed.  But that is less relevant than the fact that this must also
be true for VERS_1.3 which is what we are introducing to 4.15 here :-).

Andy, I usually agree with you on ABI matters.  I think I am doing
what you mean.  Please correct me if I have misunderstood you.  If
what I hnve done is wrong, we should revert and/or fix it quickly on
staging-4.15.

(I'll ping you in IRC when I have pushed my queue to staging-4.15.)

Ian.