From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22930 invoked by alias); 27 Nov 2018 14:33:58 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 22916 invoked by uid 89); 27 Nov 2018 14:33:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SEM_URI,SEM_URIRED,SPF_PASS autolearn=no version=3.3.2 spammy=2020, workable, jessie, additions X-HELO: mail-qt1-f195.google.com MIME-Version: 1.0 References: <87bm6cou8a.fsf@oldenburg.str.redhat.com> <2ce22420-c941-1566-fde4-42eb9876678b@linaro.org> In-Reply-To: <2ce22420-c941-1566-fde4-42eb9876678b@linaro.org> From: Arnd Bergmann Date: Tue, 27 Nov 2018 14:33:00 -0000 Message-ID: Subject: Re: Fix Arm __ASSUME_COPY_FILE_RANGE (bug 23915) [committed] To: Adhemerval Zanella Cc: GNU C Library , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-11/txt/msg00697.txt.bz2 On Mon, Nov 26, 2018 at 7:14 PM Adhemerval Zanella wrote: > On 26/11/2018 14:46, Joseph Myers wrote: > > On Mon, 26 Nov 2018, Florian Weimer wrote: > >>> 2018-11-23 Joseph Myers > > > > (I think kernel 4.4, when many socket syscalls can be assumed to be > > available everywhere, will be the next point where there are significant > > simplifications to be gained in glibc sources by increasing the global > > minimum kernel version supported - many of those functions will be able to > > move to just having a single entry in syscalls.list.) > > > On same discussion I also raised, from Florian's suggestion, about focal > points relating to libc kernel iteration and Arnd Bergmann and Peter Anvin > volunteered. I am ccing them so we can improve the syscall additions for > new Linux releases. > > Arnd also said the idea is to have the new 64-bit time_t syscalls for all > affected architectures when it is accepted upstream. Regarding the minimum releases, I assume the y2038 work will require a split of the minimum runtime kernel version and the minimum kernel header version. I'd aim for 4.21 or 4.22 to be the first kernel version that has workable kernel headers for all sytem calls and ioctls, on all architectures, so this would likely become the minimum version for building glibc again for a long time. As the runtime minimum version, 4.4 sounds reasonable, this is also the oldest longterm stable kernel we currently support aside from the ancient 3.16 release used primarily by Debian Jessie (oldstable). This will be three years old by the time glibc-2.29 gets released. The last time the minimum kernel version was raised in glibc-2.24, the linux-3.2 release was 4.5 years old, the final stable 3.2.x release was this summer after 6.5 years.If you wanted to go by those numbers alone (ignoring technical benefits of picking a particular release), glibc could move to 3.16 minimum now, and change to 4.4 in summer 2020 when 3.16 is expected to end. When we synchronize the system calls during the y2038 work and require a new header version 4.22 or something like that, this would also make a good minimum binary version some three to six years later, and then allow removing many of the remaining differences between architectures, we just need to make sure we can of the unintended differences now and fix them. Arnd