From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2CE4C1F461 for ; Thu, 27 Jun 2019 14:11:17 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=default; b=uLj5VmqV41BcKlZ4 VdN/JeKby4ZbzD9FObzpGOHoZ8C9vwkSOWHCfin2XPV1NcsVjmOuFC6ZSjsRNgaI zFbhEJak7G6sfk0wODF5HxFwma/E67+D7hAA5weq7iDjtd03LSKFpuuym6ko9Jdo yWoxCFfw5pzI6Qv0SeRS1Z4inzU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type :content-transfer-encoding; s=default; bh=AnoKxQmjeNddJ61u/xSuff yS9Y4=; b=u6ZrU3hFFf8kRa0pW2+aib+PEWgNXB/l1oPslx0aOk7F6eur7Yw5Ar rC3CE9meibXG6HPjWiMN7rIskL7GYMOhx/PT51YD6wJ7PyE/hJAC8IHCzg+yYaZZ wv1SkRt7Johq4l1Ih4bCAY4g3iggVigiCArZJF44MYl1P4h4BkNGQ= Received: (qmail 102619 invoked by alias); 27 Jun 2019 14:11:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 102607 invoked by uid 89); 27 Jun 2019 14:11:14 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mailbackend.panix.com MIME-Version: 1.0 References: <87o92kibdz.fsf@oldenburg2.str.redhat.com> <20190626163908.GA13251@altlinux.org> <530DF2A2-2D76-43F6-81D0-405EFE097A57@brauner.io> <5f740811-e7d7-6ece-4156-89651666e416@redhat.com> In-Reply-To: <5f740811-e7d7-6ece-4156-89651666e416@redhat.com> From: Zack Weinberg Date: Thu, 27 Jun 2019 10:10:55 -0400 Message-ID: Subject: syscall wrappers policy (was re: glibc at the Toolchains microconference) To: "Carlos O'Donell" Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [sorry about the blank reply earlier, I pushed the wrong button] On Wed, Jun 26, 2019 at 5:04 PM Carlos O'Donell wrote: > > Could you please review the language here: > https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers > > I drafted it in 2014-10-23 based on comments from Joseph Myers and the > community (almost 5 years ago!) This seems mostly right to me, but I have some concerns. First, I think we need a definition of =E2=80=9Csyscall wrapper.=E2=80=9D = Proposed: A syscall wrapper is a function that, on a system with a traditional Unix-style kernel (i.e. we don=E2=80=99t look at Hurd when assessing this) does substantially all of its work by calling into the kernel. It may shuffle its arguments around, it may translate between the glibc ABI and some lower-level ABI, and it may not actually perform a system-call trap (e.g. `clock_gettime`), but it couldn=E2=80=99t do what it does without invoking kernel code, and it doesn=E2=80=99t do any nontrivial work itself. The =E2=80=9Cnontrivial work itself=E2=80=9D part is meant to draw a line w= ith `open` and `signal` on the =E2=80=9Cis a syscall wrapper=E2=80=9D side (even thoug= h, on modern systems, the =E2=80=9Ctrue=E2=80=9D system calls they use are named = `openat` and `rt_sigaction` respectively), and `pthread_mutex_lock` on the =E2=80=9Cisn=E2=80=99t a syscall wrapper=E2=80=9D side (even though it does= make system calls under some circumstances, it does a lot of work itself). I would like to tighten this up but I=E2=80=99m not having any luck thinking of a better= way to phrase it. Second, I think we need to talk a bit about the rationale for the policy. Something about how it has traditionally been the C library=E2=80= =99s responsibility to provide minimally mediated access to all of the functionality of the kernel, and how in the past GNU libc has hesitated to add Linux-specific syscall wrappers on portability and/or backward compatibility grounds, but we now think that was a mistake. > * If a syscall is obsoleted by another syscall (or otherwise > considered obsolete), there is no need to add a wrapper to glibc. In the user-facing documentation (not necessarily the consensus rules) it might be worth adding some kind of reassurance that we=E2=80=99re not go= ing to get rid of `open` even though it _is_ traditionally a =E2=80=9Csyscall wrapper=E2=80=9D and `openat` supersedes it. =E2=80=9CExisting functions t= hat traditionally were syscall wrappers will be preserved, even if the syscall that does exactly what they do is obsoleted by a newer one with broader capabilities, if they are specified by ISO C and/or POSIX, or if they are widely used=E2=80=9D or something like that. But, at the same time, we _do_ need to say that syscall wrappers that are OS-specific are subject to weaker compatibility guarantees. We have, after all, been removing things like nfsservctl and ustat. > * If a syscall cannot meaningfully be used behind glibc's back, or > is not useful in the glibc context except for in the ways in which > it is used by glibc I would prefer to narrow this to something like what I said in my previous message: =E2=80=9Cglibc will not provide wrappers for syscalls tha= t are _impossible_ to use from a program linked against glibc without corrupting glibc=E2=80=99s internal data structures. For instance, `set_thread_area`, `set_tid_address`, `set_robust_list`.=E2=80=9D =E2=80=9CMeaningfully used=E2=80=9D and =E2=80=9Cnot useful in the glibc co= ntext=E2=80=9D are too fuzzy and I=E2=80=99m worried we will be setting ourselves up for arguments= . > * If there's a glibc function that's not quite a direct wrapper of > the syscall but provides all the functionality of it that can > usefully be used in a program using glibc, there is no need =E2=80=A6 > * Wrappers should be added =E2=80=A6 unless there is a clear reason not t= o I do not understand the rationale for these exceptions. Did you have specific cases in mind when you wrote these? (I=E2=80=99m particularly concerned that the =E2=80=9Cnot quite a direct wr= apper=E2=80=9D rule would be used to argue against exposing a variant of `clone` that returns twice like `fork` does, which is a thing I think we should have. You probably _can_ do any fork-with-options operation with the `clone` wrapper we have, but having to separate the child-side code to its own function and allocate stack space for it can be a serious obstacle.= ) zw