On 15.07.2021 19:16, Andrew Cooper wrote: > On 15/07/2021 08:58, Jan Beulich wrote: >> 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) >> >> 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 > > 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
Right. A matter of remembering at the right point (if need be). That's where I think the risk is. (And of course I understand you meaning VERS_1.3 and VERS_1.4 respectively for "fixed and released" and "bump to".) If we did so, what I can't tell offhand is whether any ABI-checker data would need updating then. > 2) *All* ABI changes up to VERS_1.2 are backported. > > > 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. I'm afraid I'm less clear about this part: There shouldn't be any ABI differences in VERS_1.2 in the first place, should there? Or, if the number is again off by one, the sole new function would be identical (ABI-wise) everywhere. Jan
