From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id CCBCB3858C00 for ; Wed, 21 Sep 2022 16:50:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCBCB3858C00 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.93,333,1654588800"; d="scan'208";a="83469501" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 21 Sep 2022 08:50:13 -0800 IronPort-SDR: 5lZZLgh7KsU05alumHzM/ZvWle3kA8mJzJuw8p4oJ9QXrE6hwi7m34hQ1GMLdUMbZizaxQB4O3 zdDQUicS7yUmPaOrVbvyBEfuYZRkRscq9GdO6C7YmpCxuR187Dawr7KkuILQGkkgGukIJNFdgd f2MC5/Bxgu4A9fe4SqitW4FcStwqnIUpMWqcFnpV3XNIP8B25YsUGSIiv97i3948jldqaMw+XO yJ+/ljTMLih9SL/+Lcqdzk4VKDuIiyj+J4rINazcNUkF0e7EkL0EbPhL/9b7gFsnqW6MTSxeQN iU4= Date: Wed, 21 Sep 2022 16:50:08 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Stefan Liebler CC: GNU C Library Subject: Re: Question: Is there a plan when to require a higher Linux kernel version than 3.2? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3111.1 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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