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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/08/2021 17:43, Ian Jackson wrote:
> 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.

Yes

>
> 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.

That's probably ok, but I'd be tempted to backport that fix too.

> 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.

We don't proactively bump the stable libs sonames - they get bumped on
first new addition.

Otherwise, if there is no addition between now and the 4.16 release,
then the 4.16 build will produce a libfoo.so.1.4 with 1.3's effective ABI.

The same would be true in general for every stable library we didn't
modify in a specific release cycle.

>
> 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.

Oops - my mistake.

>
>> 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.

Looks good to me.

~Andrew