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

Re: preparations for 4.15.1 and 4.13.4

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 16 Jul 2021 08:16:36 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=UfJpp0K1fMU1G9vcr87o7TTVTssxVrLdUkzsRyMWPRI=; b=E3clQHMxQ9bK1oEhWI8AnP5JIq2Xte9SjMac6KEr5wshG36XtEChNVAHYw/QBdewMeUblz7Oboons95sfmzHJPM9kOKkxQtSteLZskYJDmGaIvzomk37Xvkd6bi8rb3u7GHJaRej2ShRg4Zcn29fw3R+8KTlmhH9ReUH5rBycddBoXk7B/fHW4KZ4ffIabLUl7396dDA0rGwPjuilTV3rXKGfjfEYAMdEu0GPeWdZaDFO/nS1YRp427lNubN36mHU1Az5+H8EhnVyRe6AEet0kvL0CXp51OzcMOrWyDYaYPKv0fu0LZdpQh99jfhy3ndEsXGSLA9tVyzUeaZkQWhTA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RRlbv9IbbhlfwLR8RRCAL02DE0j08IYgRVv0UOQkOQstFISGcDVwFoKYD+NU0KYEOkkNw3XcvFf54VTC+ZEL1wDh1fUuJ1ENRtBOMSzJ+bQsovbzZw56BzHeOoVXgFvg523jaNZ3X6TArJ+p5AhWk5gewDkhqP0UYF5+euBSLR+9+qpaCuNDjtAYe9/bizhxnObMVTZIcYzul2jWX9UyzNQSaLVFex/hwOoA6MrUSGPozGN/C+IOmSRdx0siMyQxGvo0jNi8NGabFUN0XHcD/SxVfmZi51CUSKMd0oRyPVm3jq0eVi/z4XUdCUkZQyaQia/I9dqY7ghNWxuOnfYjhQ==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxx>
  • Delivery-date: Fri, 16 Jul 2021 06:16:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

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.




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