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=-4.0 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 ACBC11F461 for ; Thu, 27 Jun 2019 15:49:03 +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:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=Xs3NNJaNwaiNHHwYSFyKzg1Rr2JGU645mg4HkAqfw1582lkQGk0FV UOoixqjWf9CUc9HqgSc3B3vRxhV/MVo8Qj5JALopXbb8hFGqeVBqszViDfPnUEdb HEAWf3qa40vkwvIqOgptJ/IlMkB/bbF1DrKw8NnBThbHI5+xc5ntfM= 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:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type:content-transfer-encoding; s=default; bh=a3wjd/pgyRY/Grj4omlGgV4PjkM=; b=RDMnXv1/LJk0cjNy0Y6WjpF7xNCa SiwUeII3/9sdQBjMhwDpTa5jnehRjgVR7qxbf18aam3DQHCEkBffjuf8kfW3m6xu FlwnoQjA3BPI1SIOkf9b8+c3HdZrY+UL17Kju3W61cosy55UNeDa0oijspAxW182 57C6Cai8jUlhgj0= Received: (qmail 73585 invoked by alias); 27 Jun 2019 15:49:01 -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 73432 invoked by uid 89); 27 Jun 2019 15:49:01 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: DJ Delorie To: Zack Weinberg Cc: carlos@redhat.com, libc-alpha@sourceware.org Subject: Re: syscall wrappers policy (was re: glibc at the Toolchains microconference) In-Reply-To: (message from Zack Weinberg on Thu, 27 Jun 2019 10:10:55 -0400) Date: Thu, 27 Jun 2019 11:48:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Zack Weinberg writes: > First, I think we need a definition of =E2=80=9Csyscall wrapper.=E2=80=9D= Proposed: I offer alternate wording, not because I think mine is better, but to stir the pot a bit and get people thinking :-) "A syscall wrapper is a function whose primary (preferably sole) purpose is to provide a minimal C-callable interface to a kernel function." I think that explains why glibc has them (C-callable), limits its scope (primary/sole purpose) and defines its purpose (kernel function). How glibc implements them, and how much it needs to do to retain compatiblity with other C APIs and standards, can be documented separately. Or we could add ", consistent with other glibc functions" to the end of the above. > Second, I think we need to talk a bit about the rationale for the > policy. I think definining it as a "C API" makes it clear that the C library is the right place for C functions. That also keeps us from trying to be the ONLY kernel API library, when other languages need non-C wrappers.