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

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

  • To: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 19 Aug 2021 17:56:13 +0100
  • 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=tlmvmu1H259mfHoV7cWTKiw5Oox7kxRba5Xf2uLSN8M=; b=VtUO9H9mUaAvBBMUE01Ullm/YAlCagTdgH45iqEsgfLhOpO5TDXfWnWGPNIaI0uqTaq/aWc7KjcV8/7Xjpe+L5TXeBmRt9nkf6yOtcYW1l7y312dmQSROiImZzACT+tl2r6J8obj5HWiTJO8svmAhbucra+WLYnC/e6c5AeUbu0QA4t6QTweYVTzDcHNzrxc9RzNHiiKQuKCu4pLuu2W0IH7urEPsbpu+8qqUeaYxpU5uq8QiKVdva/yjLPJ2BvtznJFvDGCWGX1XqevjDDw/P7P/3NaFKUJM4mhWzvxlQsB11QmNIR/AWyxwwJIdCgMZgJy8wVpGt/TZgeHzJziBw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oApYPki5F725pbk93gtMDngABGRQMIOPaReeMLKMPefH4aqs+z0N/PNGHsbbLPRdHyMKxcZX0/Cq5WoHSkXBveWiwn6GKTyFp8DokUCI+RSdfSRUi6OypcDxV4QB6iaR0l7KPkDxqVaSXqceCvGfiu4HKMYDxuVarx/Lt0Z1M0w6ZmVOdCd3WMGjdvmEQ56MIB2uvdGN3qQbbY2y84f08ts2GPQm+ezIe7lWi5Qus5TdD9JOnMI0H2LsaiUwqsX2fdvs313TbQlOgaBGa7FklcTsGilcHWT92/v0IawXsY5h4cBH4IOD7WU4a5ceUxtBPMK8pXPMSHbYhebsFCUPQw==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Thu, 19 Aug 2021 16:56:28 +0000
  • Ironport-hdrordr: A9a23:XHUkgKldU+7StZWDtYiywa9NQc3pDfOiimdD5ihNYBxZY6Wkfp +V88jzhCWZtN9OYhwdcLC7WZVpQRvnhPtICPoqTMiftW7dyReVxeBZnPbfKljbdREWmdQtrZ uIH5IOb+EYSGIK9/oSgzPIY+rIouP3iZxA7N22pxwGLXAIGtNdBkVCe2Km+yVNNXh77PECZf yhD6R81lidkDgsH7+G7i5vZZm8mzSHruOoXTc2QzocrCWehzKh77D3VzCewxclSjtKhZMv63 LMnQDV7riq96jT8G6c60bjq7Bt3PfxwNpKA8KBzuATNzXXkw6tIKBsQaeLsjwZqPymrHwqjN 7PiRE9ONkb0QKeQkiF5T/WnyXw2jcn7HHvjXeenHvYuMT8AAk3DsJQ7LgpOCfx2g4FhpVRwa hL12WWu958FhXbhhnw4NDOSlVDile0iWBKq59Qs1VvFa8lLJNBp40W+01YVL0aGjjh1YwhGO 5ySOnB+fdtd0+AZXyxhBgt/DWVZAV2Iv66eDlEhiTMuAIm2kyRjnFohPD3p01wsa7UEPJ/lr 352s0CrsA8cicUBZgNT9vpD/HHUlAk7Hr3QRSvyG/cZdU60kT22tbKCYUOlZSXkaMzvewPcb T6IR5lXD0JCg7T4fPn5uwDzvmKehTnYQjQ
  • Ironport-sdr: LsirwRQxWz987v+dZEX449nldelerDFzs0B8+gKCzgZlGsxn/3OwrnJNZ3Q+n+cNmS7BY+7CLC wPwVkf6MVVZeK4Grt0gxAFQgl2c4DBnT1OyEmiqN8FmBXahcV7RH+6Nq5qo0t0WtW00cOqN8xP 2P+FOjh66XTZb6w1rwDX8kpbfMZu/VPt/uBsqmR7tY1fLmRyDQ7bg606ZAc6XowG80plM831af 7Oy2+6kmC2fWnC5nvxmhYL+aTMDM16IwkgulntASfy45Y3ekMwZGO5xrVh7G7JJubMghbrJSsM T1Ds9VJ9o0sxurSu0XMs/v6v
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.


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




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