* Question: Is there a plan when to require a higher Linux kernel version than 3.2?
@ 2022-09-20 9:11 Stefan Liebler
2022-09-20 9:40 ` Xi Ruoyao
2022-09-21 16:50 ` Joseph Myers
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Liebler @ 2022-09-20 9:11 UTC (permalink / raw)
To: GNU C Library; +Cc: Joseph S. Myers
Hi,
the minimum required Linux kernel version is currently 3.2 which was set
with commit 5b4ecd3f95695ef593e4474b4ab5a117291ba5fc
"Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere." back
in 2016.
Is there a plan when to require a higher Linux kernel version and which
version will then be used as minimum?
Some background on my question:
On s390x, unfortunately the direct socket syscalls are not used due to
the __ASSUME_* macro undefines in
sysdeps/unix/sysv/linux/s390/kernel-features.h if Linux kernel version
<4.3 is used.
Bye,
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: Is there a plan when to require a higher Linux kernel version than 3.2?
2022-09-20 9:11 Question: Is there a plan when to require a higher Linux kernel version than 3.2? Stefan Liebler
@ 2022-09-20 9:40 ` Xi Ruoyao
2022-09-20 9:56 ` Stefan Liebler
2022-09-21 16:50 ` Joseph Myers
1 sibling, 1 reply; 6+ messages in thread
From: Xi Ruoyao @ 2022-09-20 9:40 UTC (permalink / raw)
To: Stefan Liebler, GNU C Library; +Cc: Joseph S. Myers
On Tue, 2022-09-20 at 11:11 +0200, Stefan Liebler via Libc-alpha wrote:
> Hi,
>
> the minimum required Linux kernel version is currently 3.2 which was set
> with commit 5b4ecd3f95695ef593e4474b4ab5a117291ba5fc
> "Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere." back
> in 2016.
>
> Is there a plan when to require a higher Linux kernel version and which
> version will then be used as minimum?
>
> Some background on my question:
> On s390x, unfortunately the direct socket syscalls are not used due to
> the __ASSUME_* macro undefines in
> sysdeps/unix/sysv/linux/s390/kernel-features.h if Linux kernel version
> <4.3 is used.
You can use --enable-kernel=4.3 in your build if you won't use it on
Linux < 4.3.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: Is there a plan when to require a higher Linux kernel version than 3.2?
2022-09-20 9:40 ` Xi Ruoyao
@ 2022-09-20 9:56 ` Stefan Liebler
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Liebler @ 2022-09-20 9:56 UTC (permalink / raw)
To: Xi Ruoyao, GNU C Library; +Cc: Joseph S. Myers
On 20/09/2022 11:40, Xi Ruoyao wrote:
> On Tue, 2022-09-20 at 11:11 +0200, Stefan Liebler via Libc-alpha wrote:
>> Hi,
>>
>> the minimum required Linux kernel version is currently 3.2 which was set
>> with commit 5b4ecd3f95695ef593e4474b4ab5a117291ba5fc
>> "Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere." back
>> in 2016.
>>
>> Is there a plan when to require a higher Linux kernel version and which
>> version will then be used as minimum?
>>
>> Some background on my question:
>> On s390x, unfortunately the direct socket syscalls are not used due to
>> the __ASSUME_* macro undefines in
>> sysdeps/unix/sysv/linux/s390/kernel-features.h if Linux kernel version
>> <4.3 is used.
>
> You can use --enable-kernel=4.3 in your build if you won't use it on
> Linux < 4.3.
>
Yes, you are right.
For my custom build I can use this configure flag.
But I think the distros will configure glibc either with their own
defined kernel-version or will align to the minimum kernel version used
with glibc-upstream.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: Is there a plan when to require a higher Linux kernel version than 3.2?
2022-09-20 9:11 Question: Is there a plan when to require a higher Linux kernel version than 3.2? Stefan Liebler
2022-09-20 9:40 ` Xi Ruoyao
@ 2022-09-21 16:50 ` Joseph Myers
2022-09-21 23:07 ` Michael Hudson-Doyle
1 sibling, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2022-09-21 16:50 UTC (permalink / raw)
To: Stefan Liebler; +Cc: GNU C Library
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: Is there a plan when to require a higher Linux kernel version than 3.2?
2022-09-21 16:50 ` Joseph Myers
@ 2022-09-21 23:07 ` Michael Hudson-Doyle
2022-09-22 16:59 ` Joseph Myers
0 siblings, 1 reply; 6+ messages in thread
From: Michael Hudson-Doyle @ 2022-09-21 23:07 UTC (permalink / raw)
To: Joseph Myers; +Cc: Stefan Liebler, GNU C Library
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Thu, 22 Sept 2022 at 04:50, Joseph Myers <joseph@codesourcery.com> wrote:
> * 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 don't know how seriously you are suggesting moving the baseline to 4.9 or
on what timeframe, but we (Canonical) still have Ubuntu 14.04 (kernel 3.13)
in extended support until 2024 and 16.04 (kernel 4.4) until 2026 and we
would like these users to be able to use newer distributions in containers
(I don't know RHEL's policies, but by my reading RHEL7, based on kernel
3.10, is in a similar kind of extended support until 2026). So I don't want
to hold up progress to a new and better world too much... but also there is
a reason to move slowly here.
Cheers,
mwh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: Is there a plan when to require a higher Linux kernel version than 3.2?
2022-09-21 23:07 ` Michael Hudson-Doyle
@ 2022-09-22 16:59 ` Joseph Myers
0 siblings, 0 replies; 6+ messages in thread
From: Joseph Myers @ 2022-09-22 16:59 UTC (permalink / raw)
To: Michael Hudson-Doyle; +Cc: Stefan Liebler, GNU C Library
On Thu, 22 Sep 2022, Michael Hudson-Doyle via Libc-alpha wrote:
> On Thu, 22 Sept 2022 at 04:50, Joseph Myers <joseph@codesourcery.com> wrote:
>
> > * 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 don't know how seriously you are suggesting moving the baseline to 4.9 or
> on what timeframe, but we (Canonical) still have Ubuntu 14.04 (kernel 3.13)
> in extended support until 2024 and 16.04 (kernel 4.4) until 2026 and we
> would like these users to be able to use newer distributions in containers
I think that container hosts running much newer distributions in
containers must be expected to update the host kernel, or backport some
new syscalls, rather than expecting new distributions to have libc working
on a ten-year-old kernel. (New distributions probably do want to have
libc that works on the kernel used by any prior version of that
distribution from which in-place upgrades are supported, but that
shouldn't require support for ten-year-old kernels.)
To benefit significantly (in terms of source code cleanup) from updating
the minimum kernel in glibc, I think the new minimum would need to be at
least 4.4; older versions wouldn't allow removing lots of socketcall code,
so I don't think an update would be worthwhile until we're ready to move
to 4.4 or later as the new minimum.
(Technically there's also the option of having an older minimum version on
x86_64, which we did for a while before, since x86_64 doesn't use
socketcall anyway so much of the benefit could be gained by updating the
minimum on other architectures.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-09-22 16:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-20 9:11 Question: Is there a plan when to require a higher Linux kernel version than 3.2? Stefan Liebler
2022-09-20 9:40 ` Xi Ruoyao
2022-09-20 9:56 ` Stefan Liebler
2022-09-21 16:50 ` Joseph Myers
2022-09-21 23:07 ` Michael Hudson-Doyle
2022-09-22 16:59 ` Joseph Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).