Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4641162imu; Mon, 12 Nov 2018 14:35:57 -0800 (PST) X-Google-Smtp-Source: AJdET5fciP0D5S4okyTByCDQgzCgjZOFXY2X/Osszcmbj4EFi4s0A7ULkOQ6eKLszwv2KRoChcAh X-Received: by 2002:a17:902:28a8:: with SMTP id f37-v6mr2663403plb.264.1542062157539; Mon, 12 Nov 2018 14:35:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542062157; cv=none; d=google.com; s=arc-20160816; b=hvC8phru8mHAvoXcnirijRTgocLk5h/iNRRYh/IXh2StKQkQnMhwkEGFV/rSC/buG6 +s0GC/r/P16ZGJ3wblcnOS0qbsG3u5n3yZeWEvSriUrCkG329fEyPUefuicxDIInv6pL ceWkKjD7NQqtspOj2HndrDGEG93phdRTUo1DnYIIuRdyRC5YfMxguzhpvyyqe2YGYa/C DVvo4bI+qYpEV87riL2ElwkevPdfPIaqHZbkc3zn3Ob+QYf4wIws6NXl9puikMPGtDyB hBCaOyBjAThDkPHe8AwJ7GZz9wYI1Zg0C0yXeMxOMV2Tbufw4wC6qGyF1uGFtr1ZlBdR wwBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=JdNBhyukEl1V9JWgYmFxY1dMUKXxAZaTBy+Wb1YaJ08=; b=IyQTCAFfgJaT+Q4ZBSBA+/f61xiHF6BcK8RkjxnxRdNqCofU7L5nXx2qGe5x6B2FCd xRzYiSELXVfc/XAhLFhGeb6Ubr65VQKmzN32Ac9svp3d9huyWzVSaWYy4zGx23UR6MaK 9rSQfAKForqNFNxJWEFOuidmHLMZegiCao4WQkNGYIxVBOM8yoALe3FJavINV72MFIjF igrUo5/MzE6EDmfsCnjAYgPk40+Nm2SUqsfu89SmIAskZlTM9l6eUw81qqpXbOqV+Wiz +LGiPwoS1kjdJqd/0+XD9D01+fcwJUN5qQxb0U2ZMewTXdauZfPLrQYLbaD0iIMIKnqu 0xDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u23si17956231pgb.66.2018.11.12.14.35.41; Mon, 12 Nov 2018 14:35:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730729AbeKMI3z (ORCPT + 99 others); Tue, 13 Nov 2018 03:29:55 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:52320 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728030AbeKMI3z (ORCPT ); Tue, 13 Nov 2018 03:29:55 -0500 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-03.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gMKn2-00053X-BU from joseph_myers@mentor.com ; Mon, 12 Nov 2018 14:34:40 -0800 Received: from digraph.polyomino.org.uk (137.202.0.90) by SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 12 Nov 2018 22:34:36 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1gMKmy-0004xj-Br; Mon, 12 Nov 2018 22:34:36 +0000 Date: Mon, 12 Nov 2018 22:34:36 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Florian Weimer CC: Daniel Colascione , Zack Weinberg , "Michael Kerrisk (man-pages)" , Linux Kernel Mailing List , Joel Fernandes , Linux API , Willy Tarreau , Vlastimil Babka , Carlos O'Donell , GNU C Library Subject: Re: Official Linux system wrapper library? In-Reply-To: <87lg5ym7qi.fsf@oldenburg.str.redhat.com> Message-ID: References: <877ehjx447.fsf@oldenburg.str.redhat.com> <875zx2vhpd.fsf@oldenburg.str.redhat.com> <87lg5ym7qi.fsf@oldenburg.str.redhat.com> 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-04.mgc.mentorg.com (139.181.222.4) To SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 12 Nov 2018, Florian Weimer wrote: > For that use case, a machine-readable system call ABI specification is > the only reasonable approach: Some people want inline system calls, I also think it's much more likely to be of use to glibc than any syscall library provided by the kernel. I don't think a syscall library provided by the kernel is likely to be of use for implementing glibc functions, but some kind of textual ABI specification might at least be of use for checking that syscall macro calls / syscalls.list entries are consistent with what the kernel thinks its ABI is. (Hopefully there would be automated tests on the kernel side as well of some kind of consistency between the ABI specification and the kernel.) strace is indeed a more obvious potential consumer of such a description of syscall ABIs. I'd think a syscall library would more likely be something a few applications would use if they want to access a syscall that for whatever reason glibc doesn't have a wrapper for yet - not something useful for glibc itself to call or link against. > and for application programmer's sanity, make sure that the kernel adds > generic system calls in a single version, across all architectures. That would be strongly desirable for glibc as well - a way of ensuring that the kernel rapidly fails CI tests and does not get released if new syscalls are only present on some architectures (including e.g. being missing from some compat syscall tables, or defined in asm/unistd.h but not in the actual syscall table, or vice versa - or some way of making sure such inconsistencies cannot occur by eliminating duplicate copies of the syscall list information in the sources). When we have compatibility code in glibc for the absence of some syscall, we can only eliminate that code when the oldest kernel version supported by glibc is new enough to have the syscall on whichever glibc architecture was slowest to introduce the syscall in the kernel - and that can often be years after the first architectures gained support for that syscall in the kernel. -- Joseph S. Myers joseph@codesourcery.com