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 F26C5385700E for ; Fri, 17 Jul 2020 14:32:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F26C5385700E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: KEgEB2PKBjffviSGhE4D/6IhB4yJe/ThsDykmCwanWgpWP5DF27qgkoXrndrpIHBJLzpEJ3hCK E1eVP11ADvwWMmoLP3jP8AxTJ7Yj2mPYE6m6eN4SvIdoXqwzI69a1ZFMegYMk0apB2Gf+8VJ9D cDElfdTQr0QtMTJ8zEoEvBEVjSQ4N1ore5TZPZ4d//7kBnYjHt1UpjfCfG6Nv95zF4GUTF3dtR yCW6bRF+BpPZnHzqcrZoVTCrD38seq/toRLE3TT8vVdcPbf2QYFQL80h+R7c7ddEblz2r8p3Eo MlY= X-IronPort-AV: E=Sophos;i="5.75,362,1589270400"; d="scan'208";a="51029473" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 17 Jul 2020 06:32:06 -0800 IronPort-SDR: ClstcdLlWaKjScElBvcsP7BRgQ8JY6bWMoSXc0OCYwtGK+8vzlbwx52yFl69R91E4lZmHA2/h1 9Nqq8d4FqsC8ODJHGgfGc+BuOYWb2qZjTMb21A2wx3mK4DFq48YicIdaLGu//NTc4gqi2ElHXl ym98PyxSAXfODnl2HehOfJRoXzZEscG6vd8kDOxwtZKbsZy9GvKNEm81btUwnz7A2FgaEc37FJ hrQmJgFMeIHHF3gx/Qnog+KZfgxv/kiAY4r9mqcpdViXcTIYaxjpyCc6stOaQWoaxM+YlJKi63 Ho4= Date: Fri, 17 Jul 2020 14:32:00 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Lukasz Majewski CC: Adhemerval Zanella , Paul Eggert , Alistair Francis , Arnd Bergmann , Alistair Francis , GNU C Library , Florian Weimer , Carlos O'Donell , Stepan Golosunov , Andreas Schwab , Zack Weinberg Subject: Re: [RFC 00/10] y2038: nptl: futex: Provide support for futex_time64 In-Reply-To: <20200717092724.23fdcf9a@jawa> Message-ID: References: <20200707150827.20899-1-lukma@denx.de> <8e50e48c-f3e9-7c56-bff7-8da0d80a4bf2@linaro.org> <20200714095617.320eb56d@jawa> <20200715104738.245adf67@jawa> <780261fe-a8c2-b893-050b-c658ecd9ce59@linaro.org> <20200717092724.23fdcf9a@jawa> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3128.8 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 14:32:09 -0000 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