[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