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.9 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 0BA0A1F461 for ; Wed, 26 Jun 2019 20:33: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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=r4ZxU8eOuImPBmII 2IvzSZBhO09eYOR38mUgOnDYjmaUOzhJiiKQRSvHbAku3dFLJEKjjYPyh7FZN2OV vOv+9Lc6PxJDicNwDL5cSmT3OoO8W62EcLNhN7XovvCAhp1lcsy589gni2n7UynO a6Wq7rwHgb7EcQNRkv6ZmfGWoaY= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=SvpxINFf8r3xiwZzowEzEo WWQiQ=; b=bJov/Hei7A/s8sEHYsEnEOvlgwUUKUa9aTuSccwlMSx+XU+hcwMmBV cMLs0D88MqmepLtasIzPZ/EIAdMatFZYr7Be4xXXGRyJWgaxuXopQSH5aAalUgJj ncYgFBldYm5jeNxgyBIrvjFkZGpODTfquhheldCNo/ei30B2d2xm8= Received: (qmail 67039 invoked by alias); 26 Jun 2019 20:33: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 67031 invoked by uid 89); 26 Jun 2019 20:33:46 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f193.google.com Subject: Re: glibc at the Toolchains microconference at LPC 2019 To: Florian Weimer , Zack Weinberg Cc: "Dmitry V. Levin" , GNU C Library References: <87o92kibdz.fsf@oldenburg2.str.redhat.com> <20190626163908.GA13251@altlinux.org> <87imss1e13.fsf@oldenburg2.str.redhat.com> From: Carlos O'Donell Message-ID: Date: Wed, 26 Jun 2019 16:33:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <87imss1e13.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 6/26/19 12:56 PM, Florian Weimer wrote: > * Zack Weinberg: > >> 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. Other >> people have disagreed with me pretty strenuously, but they haven't >> done any of the work required to make forward progress on their more >> conservative policies. I am tempted to post a patch early in the 2.31 >> cycle that adds wrappers for everything, and then threaten to apply it >> unilaterally unless I hear concrete objections within a week or so. > > In my experience, it's been difficult to get reviewers. So what the > project says it wants and what the project actually makes happen is > rather different. It is difficult to get reviewers for *all* patches. Therefore I don't think this is particular to syscall wrappers. I've tried hard to review many of your syscall wrappers and make good on the promise we gave to the kernel community that we would do so. Lastly, if you do reviews please provide your "Reviewed-by" markers since it will let me run metrics on how many people we have reviewing and who they are, and use that information to for a long-term strategy for getting more reviewers. > There is currently a requirement that every wrapper needs a manual entry > (and, presumably, a test case, although I have not tested the waters on > that). membarrier is not included only because we could not agree on > the manual text. And rightly so. I would hope that we all agree that we need documentation and testing of interfaces in order to provide our users with the information they need to use these interfaces. -- Cheers, Carlos.