Re: Question: Is there a plan when to require a higher Linux kernel version than 3.2?

[Joseph Myers <joseph@codesourcery.com>]

On Tue, 20 Sep 2022, Stefan Liebler via Libc-alpha wrote:

> Is there a plan when to require a higher Linux kernel version and which
> version will then be used as minimum?

I think there were two key things being waited for:

* Removing the startup check for too-old kernel to avoid causing 
unnecessary failures for programs that don't actually end up using newer 
kernel features.  Done in commit b46d250656794e63a2946c481fda29271342dd1a.

* The oldest kernel version supported on 
https://www.kernel.org/category/releases.html (currently 4.9) being new 
enough for the change to allow significant cleanups in glibc.  I think 
that is now the case for many of the socket syscalls across all 
architectures, so that much of the socketcall support could be removed 
from glibc.

A lot of care would be needed about removing socketcall support, because 
of variations between architectures in exactly what socket syscalls are 
available in what versions.  See, for example, the comment in 
sparc/kernel-features.h:

/* These syscalls were added for 32-bit in 4.4 (but present for 64-bit
   in all supported kernel versions); the architecture-independent
   kernel-features.h assumes some of them to be present by default.
   getpeername and getsockname syscalls were also added for 32-bit in
   4.4, but only for 32-bit kernels, not in the compat syscall table
   for 64-bit kernels.  */

getpeername and getsockname were only added to the compat syscall table 
for SPARC in 4.20 (Linux commit 1f2b5b8e2df4591fbca430aff9c5a072dcc0f408).  
So even with a 4.9 minimum kernel, you can't yet assume those syscalls are 
available everywhere.

A similar analysis would need to be done for every syscall being used in 
place of socketcall, to make sure it's genuinely available on all 
supported glibc architectures, including in compat syscall tables, in the 
new minimum kernel version, before the support for using socketcall for 
that operation can safely be removed from glibc.

-- 
Joseph S. Myers
joseph@codesourcery.com