Re: [PATCH 2/3] tools/libs: Stash the 4.14 API/ABIs for the stable libraries

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.03.2021 12:26, Andrew Cooper wrote:
> On 02/03/2021 11:21, Jan Beulich wrote:
>> On 02.03.2021 12:17, Andrew Cooper wrote:
>>> On 02/03/2021 10:45, Jürgen Groß wrote:
>>>> On 01.03.21 18:00, Andrew Cooper wrote:
>>>>> These dumps were produced from the RELEASE-4.14.0 tag, with the
>>>>> abi-dumper
>>>>> tooling backported from staging.
>>>>>
>>>>> For each stable library, add a PKG_OLD_ABI variable pointing at the
>>>>> 4.14 ABI.
>>>>>
>>>>> No functional change.
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>>> ---
>>>>> CC: Ian Jackson <iwj@xxxxxxxxxxxxxx>
>>>>> CC: Wei Liu <wl@xxxxxxx>
>>>>> CC: Juergen Gross <jgross@xxxxxxxx>
>>>>> ---
>>>>>   tools/libs/abi/libxencall.so.1.2-x86_64-abi.dump   |  924 +++++++++++
>>>>>   .../abi/libxendevicemodel.so.1.3-x86_64-abi.dump   | 1491
>>>>> +++++++++++++++++
>>>>>   tools/libs/abi/libxenevtchn.so.1.1-x86_64-abi.dump |  719 ++++++++
>>>>>   .../abi/libxenforeignmemory.so.1.3-x86_64-abi.dump |  847 ++++++++++
>>>>>   tools/libs/abi/libxengnttab.so.1.2-x86_64-abi.dump | 1199
>>>>> ++++++++++++++
>>>>>   tools/libs/abi/libxenhypfs.so.1.0-x86_64-abi.dump  |  597 +++++++
>>>>>   .../libs/abi/libxenstore.so.3.0.3-x86_64-abi.dump  | 1711
>>>>> ++++++++++++++++++++
>>>>>   .../libs/abi/libxentoolcore.so.1.0-x86_64-abi.dump |  239 +++
>>>>>   .../libs/abi/libxentoollog.so.1.0-x86_64-abi.dump  |  882 ++++++++++
>>>>>   tools/libs/call/Makefile                           |    2 +
>>>>>   tools/libs/devicemodel/Makefile                    |    2 +
>>>>>   tools/libs/evtchn/Makefile                         |    2 +
>>>>>   tools/libs/foreignmemory/Makefile                  |    2 +
>>>>>   tools/libs/gnttab/Makefile                         |    2 +
>>>>>   tools/libs/hypfs/Makefile                          |    2 +
>>>>>   tools/libs/store/Makefile                          |    2 +
>>>>>   tools/libs/toolcore/Makefile                       |    2 +
>>>>>   tools/libs/toollog/Makefile                        |    2 +
>>>>>   18 files changed, 8627 insertions(+)
>>>>>   create mode 100644 tools/libs/abi/libxencall.so.1.2-x86_64-abi.dump
>>>>>   create mode 100644
>>>>> tools/libs/abi/libxendevicemodel.so.1.3-x86_64-abi.dump
>>>>>   create mode 100644 tools/libs/abi/libxenevtchn.so.1.1-x86_64-abi.dump
>>>>>   create mode 100644
>>>>> tools/libs/abi/libxenforeignmemory.so.1.3-x86_64-abi.dump
>>>>>   create mode 100644 tools/libs/abi/libxengnttab.so.1.2-x86_64-abi.dump
>>>>>   create mode 100644 tools/libs/abi/libxenhypfs.so.1.0-x86_64-abi.dump
>>>>>   create mode 100644 tools/libs/abi/libxenstore.so.3.0.3-x86_64-abi.dump
>>>>>   create mode 100644
>>>>> tools/libs/abi/libxentoolcore.so.1.0-x86_64-abi.dump
>>>>>   create mode 100644 tools/libs/abi/libxentoollog.so.1.0-x86_64-abi.dump
>>>>>
>>>>> diff --git a/tools/libs/call/Makefile b/tools/libs/call/Makefile
>>>>> index 4ed201b3b3..37a7db5395 100644
>>>>> --- a/tools/libs/call/Makefile
>>>>> +++ b/tools/libs/call/Makefile
>>>>> @@ -11,4 +11,6 @@ SRCS-$(CONFIG_SunOS)   += solaris.c
>>>>>   SRCS-$(CONFIG_NetBSD)  += netbsd.c
>>>>>   SRCS-$(CONFIG_MiniOS)  += minios.c
>>>>>   +PKG_OLD_ABI =
>>>>> ../abi/libxen$(LIBNAME).so.1.2-$(XEN_TARGET_ARCH)-abi.dump
>>>>> +
>>>> Any reason you don't add
>>>>
>>>> PKG_OLD_ABI =
>>>> ../abi/libxen$(LIBNAME).so.$(MAJOR).$(MINOR)-$(XEN_TARGET_ARCH)-abi.dump
>>>>
>>>> to tools/libs/libs.mk, maybe with some way to override/disable the
>>>> setting (e.g. by setting a different value for PKG_OLD_ABI just
>>>> after including $(XEN_ROOT)/tools/libs/libs.mk) ?
>>> The problem is with libraries which have changed in staging, where
>>> $MINOR differs by 1.  I chose not to wildcard in ../abi/ to reduce the
>>> chance of picking up the wrong ABI to check against.
>>>
>>> Something needs to be a statement of which is the appropriate $MINOR to
>>> use, and it shouldn't be the change to bump the soname, as that is a
>>> change we want to be tested.
>> Introduce OLD_MINOR or ABI_OLD_MINOR?
> 
> That's not bisectable if it isn't in the changeset which bumps the soname.

Setting OLD_MINOR isn't tied to bumping of the soname, is it?
Instead I thought it would be part of the release process, i.e.
for every stable library OLD_MINOR would latch the value of the
present MINOR at the same time as the previous version's dumps
get installed, and maybe also at the same time as the Xen
version gets bumped (and the tree re-opened).

You said you didn't use wildcards - are you intending to have
more than a single prior version's dumps to be in the tree?
Otherwise it would seem to me that wildcard use could be
precisely the way to avoid having to record the old MINOR
anywhere (else).

Jan