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.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 B4D4C1F461 for ; Thu, 27 Jun 2019 10:19:05 +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:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=DwV3 HNPxaXeJt98r/6xr4JNFnAHtq733FaFpabe2dGVV1psxprH40H9yl9YgHd2Ml/k8 EgYemZ1KcCIfziD3w0SUmXsYeLcIbnpzSHqxX4ZIfsjWrG679X3DdAS1rzcsIzMy kF6piKLU3l65S9EJL++Q83jwdjQra/A3W/Z2CIE= 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:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=Gd0ccCCCQe g7x3BoYftP1PkvefA=; b=ai+pc2AicN2wY82NlJaNuaDzKQOE6VaAAB87kkIbf7 0iIjEIfiib9DwvmovG2Odoz3rWnX05SNBdM4xDy8sWWyajxRXMf7ldfxbYwMQMc6 03YV5wt9nu19rbg9J82oZ2cnQYidyEyibmXAzsWGGQSEqU18A6X6+WWbQCUSe0MY E= Received: (qmail 39528 invoked by alias); 27 Jun 2019 10:19:03 -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 39519 invoked by uid 89); 27 Jun 2019 10:19:03 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-wr1-f65.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JNmzel3YvAhTi9wE4y4O+INhZxXPkV6uRqXo+lSl6Qg=; b=BmgMDe5D7R01Z9Tlqw6iZ8r2Ot+7oYMK9w9yV2CIPF5DHOHkE+3hj6o1zsCD9JXoP2 sOIwS9IFoS8nagjxc/rckpkkRgp3Lp05nqJNJwpwrfiwx+dh1ZnkyDDP1R0OHnpgW4a3 FZKobnhdl7zKpNtkwS3j6toHY+TIrB4frGgZb9kpZlGtCnDjwE+VHQeJSD1fwdEGJubr ZZElF/a26ZFJK8quCMVS1MSBMjpP3kE3VzSlm4K2TKNl/lYuO0oo70odqsGBh4k8/UtH QIDXEMOl36ctrU2oWBTUIMQbUnCyRjBMkYdJDIi7GRzYOkl0l6AJvmmiAWFTL3dOKMZG xN8w== Date: Thu, 27 Jun 2019 12:18:58 +0200 From: Christian Brauner To: Szabolcs Nagy Cc: "Dmitry V. Levin" , Carlos O'Donell , nd , "libc-alpha@sourceware.org" , Zack Weinberg Subject: Re: glibc at the Toolchains microconference at LPC 2019 Message-ID: <20190627101857.vkmxhjfspb3grmj7@brauner.io> 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> <20190627093928.GA25423@altlinux.org> <16b23696-9318-714b-07f2-5a57c7c57ed3@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <16b23696-9318-714b-07f2-5a57c7c57ed3@arm.com> User-Agent: NeoMutt/20180716 On Thu, Jun 27, 2019 at 10:05:24AM +0000, Szabolcs Nagy wrote: > On 27/06/2019 10:39, Dmitry V. Levin wrote: > > On Wed, Jun 26, 2019 at 05:04:52PM -0400, Carlos O'Donell wrote: > > [...] > >> Could you please review the language here: > >> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers > > > > I suggest adding that there is no need to add wrappers for those syscalls > > that already have dedicated libraries. > > > > For example, such multiplexers as bpf(2) and keyctl(2) already have > > dedicated libraries (libbpf and libkeyutils, respectively) that provide > > APIs on top of these raw syscalls. > > there are many issues doing raw syscalls e.g. > the x32 type mess or cancellation support. > > external library projects can have different level > of quality, supported abis, header conformance, > security process etc. and they almost always mix > libc and linux uapi headers and types. > > so i'm against relying on external libraries > doing raw syscalls (they may provide additional > functionality but the syscall itself should > be in libc) I agree. Not just does the quality of those libraries often vary wildly. Sometimes there are competing libraries and it is unclear which one is properly maintained and which one is not. (A good example are the capability libraries libcap2 and libcap-ng (or whatever it's called).) I think that (g)libc should not make a judgement on whether or not a syscall should be exposed apart from the caveats Carlos and Zack already pointed out. It's a massive paintpoint for userspace if the only options are: link against a (possibly unmaintained) library or do the raw syscall yourself. Christian