Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Jackson <iwj@xenproject.org>
CC: Wei Liu <wl@xen.org>
---
tools/libs/call/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/call/Makefile b/tools/libs/call/Makefile
index 4ed201b3b3..93d404b79e 100644
--- a/tools/libs/call/Makefile
+++ b/tools/libs/call/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
include $(XEN_ROOT)/tools/Rules.mk
MAJOR = 1
-MINOR = 2
+MINOR = 3
SRCS-y += core.c buffer.c
SRCS-$(CONFIG_Linux) += linux.c
--
2.11.0
On 24.06.2021 19:55, Andrew Cooper wrote: > Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long") Is this strictly necessary, i.e. is a Fixes: tag here warranted? I wonder in particular with the possibility of backporting in mind, where I think we shouldn't easily alter SONAME and file name. Jan > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > --- > CC: Jan Beulich <JBeulich@suse.com> > CC: Ian Jackson <iwj@xenproject.org> > CC: Wei Liu <wl@xen.org> > --- > tools/libs/call/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/libs/call/Makefile b/tools/libs/call/Makefile > index 4ed201b3b3..93d404b79e 100644 > --- a/tools/libs/call/Makefile > +++ b/tools/libs/call/Makefile > @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../.. > include $(XEN_ROOT)/tools/Rules.mk > > MAJOR = 1 > -MINOR = 2 > +MINOR = 3 > > SRCS-y += core.c buffer.c > SRCS-$(CONFIG_Linux) += linux.c >
On 25/06/2021 07:31, Jan Beulich wrote: > On 24.06.2021 19:55, Andrew Cooper wrote: >> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long") > Is this strictly necessary, i.e. is a Fixes: tag here warranted? Yes - very much so. andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -Wa ../tools/libs/call/libxencall.so.1.2 | grep 1\\.3 33: 0000000000001496 59 FUNC GLOBAL DEFAULT 13 xencall2L@@VERS_1.3 39: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 76: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 020: 4 (VERS_1.2) 5 (VERS_1.3) 2 (VERS_1.0) 3 (VERS_1.1) 024: 3 (VERS_1.1) 2 (VERS_1.0) 4 (VERS_1.2) 5 (VERS_1.3) 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: VERS_1.3 Without this, you create a library called .so.1.2 with 1.3's ABI in. ~Andrew
On 25.06.2021 11:17, Andrew Cooper wrote: > On 25/06/2021 07:31, Jan Beulich wrote: >> On 24.06.2021 19:55, Andrew Cooper wrote: >>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long") >> Is this strictly necessary, i.e. is a Fixes: tag here warranted? > > Yes - very much so. > > andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -Wa > ../tools/libs/call/libxencall.so.1.2 | grep 1\\.3 > 33: 0000000000001496 59 FUNC GLOBAL DEFAULT 13 > xencall2L@@VERS_1.3 > 39: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 > 76: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 > 020: 4 (VERS_1.2) 5 (VERS_1.3) 2 (VERS_1.0) 3 > (VERS_1.1) > 024: 3 (VERS_1.1) 2 (VERS_1.0) 4 (VERS_1.2) 5 > (VERS_1.3) > 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: VERS_1.3 > > Without this, you create a library called .so.1.2 with 1.3's ABI in. I'm aware of the change to file contents as well as the disagreement of file name / SONAME vs enumerated versions. So telling me this is not really an answer to my question. It may be by convention that the two should match up, but I don't see any functional issue (yet) if they don't. Plus of course you leave open altogether the backporting aspect of my question. Jan
Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new functionality"): > On 25.06.2021 11:17, Andrew Cooper wrote: > > On 25/06/2021 07:31, Jan Beulich wrote: > >> On 24.06.2021 19:55, Andrew Cooper wrote: > >>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long") > >> Is this strictly necessary, i.e. is a Fixes: tag here warranted? > > > > Yes - very much so. > > > > andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -Wa > > ../tools/libs/call/libxencall.so.1.2 | grep 1\\.3 > > 33: 0000000000001496 59 FUNC GLOBAL DEFAULT 13 > > xencall2L@@VERS_1.3 > > 39: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 > > 76: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 > > 020: 4 (VERS_1.2) 5 (VERS_1.3) 2 (VERS_1.0) 3 > > (VERS_1.1) > > 024: 3 (VERS_1.1) 2 (VERS_1.0) 4 (VERS_1.2) 5 > > (VERS_1.3) > > 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: VERS_1.3 > > > > Without this, you create a library called .so.1.2 with 1.3's ABI in. > > I'm aware of the change to file contents as well as the disagreement > of file name / SONAME vs enumerated versions. So telling me this is > not really an answer to my question. It may be by convention that > the two should match up, but I don't see any functional issue (yet) > if they don't. Plus of course you leave open altogether the > backporting aspect of my question. The patch, including the Fixes tag, Reviewed-by: Ian Jackson <iwj@xenproject.org> Changing minor version in the filename as well as the .so is not an impediment to backporting. The actual soname remains the same so there is no compatibility problem and the change is still suitable for including in eg distro stsable releases. Not changing the filename is quite strange. I havne't thought through all of the implications but I'm sure it will confuse people, and it seems like to confuse at least some computer programs that handle this kind of thing. Ian.
On 25/06/2021 11:59, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new functionality"): >> On 25.06.2021 11:17, Andrew Cooper wrote: >>> On 25/06/2021 07:31, Jan Beulich wrote: >>>> On 24.06.2021 19:55, Andrew Cooper wrote: >>>>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long") >>>> Is this strictly necessary, i.e. is a Fixes: tag here warranted? >>> Yes - very much so. >>> >>> andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -Wa >>> ../tools/libs/call/libxencall.so.1.2 | grep 1\\.3 >>> 33: 0000000000001496 59 FUNC GLOBAL DEFAULT 13 >>> xencall2L@@VERS_1.3 >>> 39: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 >>> 76: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 >>> 020: 4 (VERS_1.2) 5 (VERS_1.3) 2 (VERS_1.0) 3 >>> (VERS_1.1) >>> 024: 3 (VERS_1.1) 2 (VERS_1.0) 4 (VERS_1.2) 5 >>> (VERS_1.3) >>> 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: VERS_1.3 >>> >>> Without this, you create a library called .so.1.2 with 1.3's ABI in. >> I'm aware of the change to file contents as well as the disagreement >> of file name / SONAME vs enumerated versions. So telling me this is >> not really an answer to my question. It may be by convention that >> the two should match up, but I don't see any functional issue (yet) >> if they don't. Plus of course you leave open altogether the >> backporting aspect of my question. > The patch, including the Fixes tag, > > Reviewed-by: Ian Jackson <iwj@xenproject.org> Thanks. > Changing minor version in the filename as well as the .so is not an > impediment to backporting. The actual soname remains the same so > there is no compatibility problem and the change is still suitable for > including in eg distro stsable releases. Correct, although backporting in general however is problematic. Until Xen 4.16 is released (or, we explicitly decide to make an explicit library release early), the 1.3 ABI isn't set in stone. Backports to older stable-* branches must sit on a boundary already set in stone in staging, or we'll end up with different versions of Xen having different ideas of what VERS_1.3 mean. It also creates upgrade compatibility problems created for any distro who's installs of newer versions doesn't have internet access to pull updated packages. This is a consequence of having different versions of stable libs bundled in different releases of Xen, rather than having them entirely separate and packaged by their soname alone. ~Andrew
On 25.06.2021 13:36, Andrew Cooper wrote: > On 25/06/2021 11:59, Ian Jackson wrote: >> Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new functionality"): >>> On 25.06.2021 11:17, Andrew Cooper wrote: >>>> On 25/06/2021 07:31, Jan Beulich wrote: >>>>> On 24.06.2021 19:55, Andrew Cooper wrote: >>>>>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long") >>>>> Is this strictly necessary, i.e. is a Fixes: tag here warranted? >>>> Yes - very much so. >>>> >>>> andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -Wa >>>> ../tools/libs/call/libxencall.so.1.2 | grep 1\\.3 >>>> 33: 0000000000001496 59 FUNC GLOBAL DEFAULT 13 >>>> xencall2L@@VERS_1.3 >>>> 39: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 >>>> 76: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 >>>> 020: 4 (VERS_1.2) 5 (VERS_1.3) 2 (VERS_1.0) 3 >>>> (VERS_1.1) >>>> 024: 3 (VERS_1.1) 2 (VERS_1.0) 4 (VERS_1.2) 5 >>>> (VERS_1.3) >>>> 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: VERS_1.3 >>>> >>>> Without this, you create a library called .so.1.2 with 1.3's ABI in. >>> I'm aware of the change to file contents as well as the disagreement >>> of file name / SONAME vs enumerated versions. So telling me this is >>> not really an answer to my question. It may be by convention that >>> the two should match up, but I don't see any functional issue (yet) >>> if they don't. Plus of course you leave open altogether the >>> backporting aspect of my question. >> The patch, including the Fixes tag, >> >> Reviewed-by: Ian Jackson <iwj@xenproject.org> > > Thanks. > >> Changing minor version in the filename as well as the .so is not an >> impediment to backporting. The actual soname remains the same so >> there is no compatibility problem and the change is still suitable for >> including in eg distro stsable releases. > > Correct, although backporting in general however is problematic. > > Until Xen 4.16 is released (or, we explicitly decide to make an explicit > library release early), the 1.3 ABI isn't set in stone. > > Backports to older stable-* branches must sit on a boundary already set > in stone in staging, or we'll end up with different versions of Xen > having different ideas of what VERS_1.3 mean. Which effectively means we'd have to open 1.4 despite being in the same release cycle if this change got backported. Or did I not understand correctly what you were trying to say? Jan
On 25.06.2021 12:59, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new functionality"): >> On 25.06.2021 11:17, Andrew Cooper wrote: >>> On 25/06/2021 07:31, Jan Beulich wrote: >>>> On 24.06.2021 19:55, Andrew Cooper wrote: >>>>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning long") >>>> Is this strictly necessary, i.e. is a Fixes: tag here warranted? >>> >>> Yes - very much so. >>> >>> andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -Wa >>> ../tools/libs/call/libxencall.so.1.2 | grep 1\\.3 >>> 33: 0000000000001496 59 FUNC GLOBAL DEFAULT 13 >>> xencall2L@@VERS_1.3 >>> 39: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 >>> 76: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.3 >>> 020: 4 (VERS_1.2) 5 (VERS_1.3) 2 (VERS_1.0) 3 >>> (VERS_1.1) >>> 024: 3 (VERS_1.1) 2 (VERS_1.0) 4 (VERS_1.2) 5 >>> (VERS_1.3) >>> 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: VERS_1.3 >>> >>> Without this, you create a library called .so.1.2 with 1.3's ABI in. >> >> I'm aware of the change to file contents as well as the disagreement >> of file name / SONAME vs enumerated versions. So telling me this is >> not really an answer to my question. It may be by convention that >> the two should match up, but I don't see any functional issue (yet) >> if they don't. Plus of course you leave open altogether the >> backporting aspect of my question. > > The patch, including the Fixes tag, > > Reviewed-by: Ian Jackson <iwj@xenproject.org> > > Changing minor version in the filename as well as the .so is not an > impediment to backporting. The actual soname remains the same so > there is no compatibility problem and the change is still suitable for > including in eg distro stsable releases. > > Not changing the filename is quite strange. I havne't thought through > all of the implications but I'm sure it will confuse people, and it > seems like to confuse at least some computer programs that handle this > kind of thing. I guess I'm still having trouble seeing the actual issue from not bumping the minor version of the library. This is still largely connected to me not seeing how a clean backport here would look like, in particular if we were to assume for a moment that the oldest tree to backport to did not already be at version 1.2. Jan
© 2016 - 2024 Red Hat, Inc.