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_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 119D41F461 for ; Wed, 26 Jun 2019 17:28:49 +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:message-id:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding :subject; q=dns; s=default; b=GCO2QvZ+EDu+yimanvMNJDxu1nPXbMlXAf +IG2Eq7y6/UoysOHg/2bFvlT85G1+1gac65C49zYvTTOT6NdaxphtnBV8+Q2LdMb 92YeVoSY3sndX/H0/JZbYXNceiNiHsB4a6VnGvCr8158gHLBVwB1aQogvzkY1haC l0DoMTdTw= 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:message-id:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding :subject; s=default; bh=3WHTSrk3bGGTvFyxMIbxiNii/2E=; b=aMSzt4up 60DjCY5hJJbA8/Fb+xgQ7/hbBUBBQNNKbNGH+SA0r4sjIxoUrgwRXhyCmVnL6iUc hC1vQABK6jCZaVSORhXrQcyOHIIR+O7Z85BFgh726hprwV+5U3f//ikZSwRnVRRj IGlZmCVVmhNcxcN3URzcQTrKbdVFx44nMuo= Received: (qmail 111655 invoked by alias); 26 Jun 2019 17:28:46 -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 111646 invoked by uid 89); 26 Jun 2019 17:28:46 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: ou.quest-ce.net Message-ID: <7dde7b13bc18fc9fbf32ca20723955c787ae586a.camel@opteya.com> From: Yann Droneaud To: Zack Weinberg Cc: GNU C Library , "Dmitry V. Levin" Date: Wed, 26 Jun 2019 19:28:41 +0200 In-Reply-To: References: <87o92kibdz.fsf@oldenburg2.str.redhat.com> <20190626163908.GA13251@altlinux.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.3 (3.32.3-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a01:e35:39f2:1220:9dd7:c176:119b:4c9d X-SA-Exim-Mail-From: ydroneaud@opteya.com Subject: Re: glibc at the Toolchains microconference at LPC 2019 X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ou.quest-ce.net) Hi, Le mercredi 26 juin 2019 à 12:50 -0400, Zack Weinberg a écrit : > On Wed, Jun 26, 2019 at 12:39 PM Dmitry V. Levin wrote: > > On Wed, Jun 26, 2019 at 06:01:28PM +0200, Florian Weimer wrote: > > > glibc system call wrappers are on the agenda: > > > > > > > > > > > > Will anyone from the glibc community attend and can set the right > > > expectations? > > > > What are the right expectations? > > Well, _I_ think glibc should provide wrappers for all Linux system > calls, except those that cannot be used without stomping on internal > glibc data structures (e.g. set_tid_address, set_robust_list, brk) and > those that have been completely superseded by newer syscalls. I believe many more syscalls must not be exposed by glibc by being too specific, architecture dedicated syscalls in particular. I strongly think that syscall wrappers that cannot be implemented with a single line of code should be avoided, as it's a sign a dedicated library would probably be better. Bigger wrappers should only be allowed when the provided syscall is intended to emulate some standard and/or cross-platform API. So, yes, you could probably say I'm on "conservative" side :) Regards. -- Yann Droneaud OPTEYA