This is the mail archive of the
mailing list for the glibc project.
Re: S390: Add support for vdso getcpu symbol.
- From: Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 9 May 2016 11:10:01 +0200
- Subject: Re: S390: Add support for vdso getcpu symbol.
- Authentication-results: sourceware.org; auth=none
- References: <nfv38m$q7v$1 at ger dot gmane dot org> <572A245A dot 2020202 at redhat dot com>
On 05/04/2016 06:33 PM, Carlos O'Donell wrote:
Looks good to me, but I have one question.
Why are the versions of these new symbols LINUX_2.6.29?
If the kernel really wants to follow the userspace conventions
for symbol versioning, the version of a newly added symbol is
that of the Linux version that released the symbol.
This allows users and developers to know exactly which upstream
public kernel version exported the symbol, and talk sensible about
the exported ABI/API in terms of these versions. Right now having
them all be LINUX_2.6.29 is useful only for adding compat symbols
at newer versions.
At this point it's too late, you have a release with these symbols
at these versions, and you can't change it.
Did you consider using LINUX_4.5 version for these symbols?
I had realised this version mismatch, too.
I had asked Martin about the version number before I posted the patch
and his first thought was, that it reflects the version, the symbol was
introduced. Then he realised, that it does not in this case.
But he won't change that for getcpu.
E.g. <kernel-src>/arch/powerpc/kernel/vdso64/vdso64.lds.S was extended
with __kernel_getcpu, __kernel_time.
E.g. <kernel-src>/arch/tile/kernel/vdso/vdso.lds.S was extended with
These additions were made without a new version number.
The corresponding glibc commits logically does not introduce a new
linux-version to find vdso-symbol in _libc_vdso_platform_setup(), too.
Link to discussion "Should Linux VDSO be using symbol version based on
the released kernel?"
I've pushed the patch.