From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101293 invoked by alias); 26 Nov 2018 18:14:57 -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 101282 invoked by uid 89); 26 Nov 2018 18:14:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SEM_URI,SEM_URIRED,SPF_PASS autolearn=no version=3.3.2 spammy=brought, upstream, releases, enforcing X-HELO: mail-qt1-f195.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:references:cc:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fN/NZIedDJY8Yl46bQ9S8jy2hyOZ0FP7Np6xtD3swLk=; b=cwifGlk0Fd1oa7VEldD2mGTqTmXn+fw8IV8dUSq0Cb0dCWbhv8I1gXkQAvMw1r2YfU FnrVd3fXCfOGh46krQ9i2gaVfuJTljLJOJEbQ8NfJGkXp9nenAhDvk8Lge8wOy20h+qW G8wueoDsTv2BfzCeSMXxcxCjBWPxa8m6bZKN8= Return-Path: To: libc-alpha@sourceware.org References: <87bm6cou8a.fsf@oldenburg.str.redhat.com> Cc: Arnd Bergmann , "H. Peter Anvin" From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: Fix Arm __ASSUME_COPY_FILE_RANGE (bug 23915) [committed] Message-ID: <2ce22420-c941-1566-fde4-42eb9876678b@linaro.org> Date: Mon, 26 Nov 2018 18:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-11/txt/msg00675.txt.bz2 On 26/11/2018 14:46, Joseph Myers wrote: > On Mon, 26 Nov 2018, Florian Weimer wrote: > >> * Joseph Myers: >> >>> 2018-11-23 Joseph Myers >>> >>> [BZ #23915] >>> * sysdeps/unix/sysv/linux/arm/kernel-features.h >>> [__LINUX_KERNEL_VERSION < 0x040700] (__ASSUME_COPY_FILE_RANGE): >>> Undefine. >> >> So I feel kind of bad about this—I looked for such issues after the >> first problems cropped up and just didn't seem them in the kernel source >> tree. >> >> Assuming that I'm going to implement a few system call wrappers in the >> future, how can I do a better job here? > > My approach is to examine the diffs for the kernel version that introduced > the syscall, and check whether it's present (asm/unistd.h, and syscall > table, and any relevant compat syscall table) for each (architecture, ABI) > pair supported by glibc not using the asm-generic syscall ABI. > > What we really need is for the kernel to do a better job at introducing > syscalls at the same time on all architectures, rather than just adding > them for one or two architectures, leaving it to architecture maintainers > to fill in the rest and so resulting in long delays before glibc can > actually assume a syscall to be available everywhere. > > (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.) > I brought this issue to kernel developers on latest Linux Plumber two weeks ago. We all agreed that Linux should avoid wiring up all-independent syscalls in different releases for different architectures, but currently there is no enforcing mechanism to do so. 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.