[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stable library ABI compatibility checking

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 11 Feb 2021 11:30:29 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NxirOC2dBWp+Y4kS0+ky1iYNwg2E7hOxgG6lu1IJ2lU=; b=AI4fwQYDWmRgl/2Kr+uAqRMle/PgYPBssn/T6OalkzDUnPJyTU8sTvnLJagcDKWhcJJgLh/hPW7UiBEIprOtu7Rw5hMjpiikL4jXE0xJln9ohMIxR8nRi4KOhQ9vLFAXs8gU7Tdd2cfzVsRHdpHCIfNSz5W3QEtUO8r6lsjM8NKa4qFSp/SuHc+niGYfF8Msf+hRFw+jjHwMV/oRLaPz35PT/8eKOyJZuE7Uj9kyHLW83Uz8GHfMrdYdPKe9B65GdkKFoEx3RB55tAjOguK9d65hPFk2rKztIpVnOBe/KwDDdtbAZyXrwXVf1I7Ycomr/Zw8EzMixPf/Tw2n0RQhcg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q9NC+NHHSEZquE41fmxjKbYoc+rQa+4K0QpZ3Ln/oNYoTlHSfMXDwGPiWk8aMEPBtiDMHA9my5uN+OvdsctnHE4V369GJTOfYyrVcI45K6XBIGkSM26MsrLAIgwk7OHFrEa5+T691e17C+UVJh/GVa6lDRT1M62d+MRk1uIlPsaqcbfKpjmp6KeivnJnIcK4VerXOhcxCU6TStrOlBSQy0pFaUsYpZbPQH0U/jTx6WNUY4GXFeZSoIEdxrRjBMq8LuGI5Qao3D7JWbqs0whuFT53+QrhUaRzrwqa+tmgDJIhXk5EWS2GsCnx373LJkxqUhUKmyMv7AWJ3Ksdi4nwmQ==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 11 Feb 2021 11:30:45 +0000
  • Ironport-sdr: QxDqEM/EBDAEmROhn2SH0coNZvqL2bUkVyaSV2zEW/QvqggHeZ9EhYquuAE0qbogh1a4aT6aTs LpPzTDNlM3IOWHaoZ7t5vDHSAuDpcrFiZXiNEfdcdiM3+hngSH78/9c+/ycY3DqsTzF7nplTof uFN8Fl5Hvv0TS2mLHKAybTGtK8ijf6om6bGv+bj9glK/MU61OTko8y+MvWaGNIZxILk6eih0NQ 9E3T+4PFtybUCoqoiGmNdR2tVXb3yHbYd3eILCr95H5uFEiYWi++8YK8JYGsW9Ty5MomG8u+hj AY4=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11/02/2021 11:05, Jan Beulich wrote:
> On 11.02.2021 02:08, Andrew Cooper wrote:
>> Hello,
>> Last things first, some examples:
>> http://xenbits.xen.org/people/andrewcoop/abi/libxenevtchn-1.1_to_1.2.html
>> http://xenbits.xen.org/people/andrewcoop/abi/libxenforeignmemory-1.3_to_1.4.html
>> These are an ABI compatibility report between RELEASE-4.14.0 and staging.
>> They're performed with abi-dumper (takes a shared object and header
>> file(s) and write out a text "dump" file which happens to be a perl
>> hash) and abi-compliance-checker checker, which takes two dumps and
>> produces the HTML reports linked above.  They're both debian tools
>> originally, but have found their way across the ecosystem.  They have no
>> impact on build time (when invoked correctly).
>> I'm encouraged to see that the foreignmem analysis has even spotted that
>> we deliberately renamed one parameter to clarify its purpose.
>> For the stable libraries, the RELEASE-$X.$Y.0 tag is the formal point
>> when accumulated changes in staging become fixed.  What we ought to be
>> doing is taking a "dump" of libraries at this point, and publishing
>> them, probably on xenbits.
>> Subsequent builds on all the staging branches should be performing an
>> ABI check against the appropriate lib version.  This will let us catch
>> breakages in staging (c/s e8af54084586f4) as well as breakages if we
>> ever need to backport changes to the libs.
>> For libraries wrapped by Juergen's tools/libs/ common-makefile changes,
>> adding ABI dumping is easy.  The only complicating is needing to build
>> everything with "-Og -g", but this is easy to arrange, and frankly ought
>> to be the default for debug builds anyway (the current use of -O0 is
>> silly and interferes with common distro hardening settings).
>> What I propose is tweaking the library build to write out
>> lib$FOO.so.$X.$Y-$(ARCH).abi.dump files.  A pristine set of these should
>> be put somewhere on xenbits, and a task put on the release technicians
>> checklist for future releases.
>> That way, subsequent builds which have these tools available can include
>> a call to abi-compliance-checker between the authoritative copy and the
>> one from the local build, which will make the report available, and exit
>> nonzero on breaking problems.
>> To make the pristine set, I need to retrofit the tooling to 4.14 and
>> ideally 4.13.  This is in contravention to our normal policy of not
>> backporting features, but I think, being optional build-time-only
>> tooling, it is worthy of an exception considering the gains we get
>> (specifically - to be able to check for ABI breakages on these branches
>> in OSSTest).  Backporting to 4.12 and older is far more invasive, due to
>> it being before the library build systems were common'd.
>> Anyway, thoughts?
> +1
> Not sure about the backporting effects - tools/libs/ had quite a bit
> less content in 4.14 and older, so the coverage would be smaller.

tools/libs/ has been the stable libraries, since IanC split them years
ago.  The only odd-one-out is libxenstored IIRC, which moved during the
4.15 window.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.