[RFC 00/10] y2038: nptl: futex: Provide support for futex_time64
Joseph Myers
joseph@codesourcery.com
Fri Jul 17 14:32:00 GMT 2020
On Fri, 17 Jul 2020, Lukasz Majewski wrote:
> But as fair as I can tell - more than "code base" cleanup - the raise
> of glibc minimal kernel supported version would help much more in this
> situation as code for many "use cases" would be just removed.
>
> A side remark - now the oldest LTS kernel supported is 4.4 and oldest
> supported kernel for glibc is 3.2.
> Maybe it is a good time to bump the minimal supported kernel for glibc?
Carlos was proposing to remove the runtime check that prevents glibc from
running if the kernel version is too old, on the basis that often new
features may have been backported to an older kernel or may not actually
be used in glibc for many programs, so a newer glibc could often work in a
container under a kernel reporting an older version number. I think it
makes sense to do that before increasing the minimum supported kernel
version.
An increase to 4.4 allows very little cleanup relevant for e.g. x86_64.
The main cleanup allowed is removing support for socketcall for many
socket operations (and thus probably allowing some of them to be
implemented through syscalls.list for all architectures rather than
needing custom C implementations). That requires careful checks on the
status of each such syscall for each architecture in 4.4, however - note
the comment in sparc/kernel-features.h about some syscalls having been
added for 32-bit in that version only for 32-bit kernels and not in the
compat syscall table for 64-bit kernels, so we'd need to keep support for
at least getpeername and getsockname using socketcall until 4.20 (Linux
kernel commit 1f2b5b8e2df4591fbca430aff9c5a072dcc0f408) or later is the
minimum version.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list