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 C8BBC1F462 for ; Thu, 25 Jul 2019 16:06:11 +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=leso kblB+jNvvtzl4O8VqvjN2x/DmwQgTy/smyzkITuVpGK9TnESG1WiarNcsnHyQ12N Cjrda4euC72+XohL2C1Njfh3139N1BEd2p9wVnym+CZl7JOwfK5HPkf/ry6sfKDI DSUCVj7rWqai0wggCNKX+jv3pvwnhG4YyjM3X40= 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=BE4zgp5Qu3 h4EXi+rSGNEAperpM=; b=CnnZGyl1iC+ZI/tt1x1QJw+9gcblja7HcK0L6I56Mp Fen7M1/rL1bQ8UA1ULJd1zZUnkdHA+pRjaUpnVvS9S3T25ybsPW/nhblKWnLcpLt BXk1pcMEf1d6jrNdjikNbsWRNOWakuSBYKx/Sbx6/ILzMydg4gacEiUyuvEIXJk+ o= Received: (qmail 85414 invoked by alias); 25 Jul 2019 16:06:09 -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 85405 invoked by uid 89); 25 Jul 2019 16:06:08 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-wm1-f67.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=AE4tdw3CadfCyzZBDrRTNxgxLVa/1M8vZLIO5teSVH4=; b=emAKQ1t+rJLQnfXJHFwcxweHXrS+npKnQxKSe6cCoeo7WWQIJDfBUMWLJnxNYlGIvo gNpqd3W9GXRfiLoCV29fzFlgXnIDob4EM0DeQSowICFEres1fBnjgw05BQfTb1Aip0p8 oaV+TNP1kvbRRax9qGWaQh1XC6auzELoEGT5RccPoZxGWtJ+dP74fIwFL+Smsbx+8jau s57qnt4cKcTGwIEUhi2Qc8IUNCznKbUbRL/GXEF4uY6GcSjsGOQmOWPskcCd2THnK8aW lbCai63LS8ZSfm2x/28vggSbQZA2rfHwonT7e5Jpz2oASrPQ2F+SQGOXPNx3LFU8SORh JsYA== Date: Thu, 25 Jul 2019 18:06:02 +0200 From: Christian Brauner To: Arnd Bergmann Cc: Rich Felker , Alistair Francis , "Eric W. Biederman" , Linus Torvalds , Alistair Francis , GNU C Library , Adhemerval Zanella , Florian Weimer , Palmer Dabbelt , macro@wdc.com, Zong Li , Andrew Morton , Al Viro , "H. Peter Anvin" Subject: Re: [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable Message-ID: <20190725160601.cyesh7ogq56ik4ay@brauner.io> References: <87blxn83sk.fsf@xmission.com> <20190721232336.GA30851@brightrain.aerifal.cx> <87k1c962ml.fsf@xmission.com> <20190723082857.kf2go2vfvnu7q7zd@brauner.io> <20190725044009.GJ1506@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 On Thu, Jul 25, 2019 at 03:15:35PM +0200, Arnd Bergmann wrote: > On Thu, Jul 25, 2019 at 6:40 AM Rich Felker wrote: > > On Wed, Jul 24, 2019 at 05:04:53PM -0700, Alistair Francis wrote: > > > On Tue, Jul 23, 2019 at 1:45 AM Arnd Bergmann wrote: > > > > > > > > Sounds good to me, the debate over what rusage to use should not hold > > > > up the review of the rest of that syscall. > > > > > > I'm unclear what the final decision is here. What is the solution are > > > we going to have wait4() or add P_PROCESS_PGID to waitid()? > > > > > > As well as that what is the solution to current implementations? If we > > > add wait4() then there isn't an issue (and I can drop this patch) but > > > if we add P_PROCESS_PGID then we will need a way to handle kernels > > > with waitid() but no P_PROCESS_PGID. Although my new plan is to only > > > use the waitid syscall if we don't have waitpid or wait4 so it seems > > > like this will only affect RV32 for the time being. > > > > I would really like some indication which solution will be taken, > > since it impacts choices that will need to be made in musl very soon. > > My favorite outcome would be bringing back wait4 for rv32 (and > > no-time32 archs in general) *and* adding P_PROCESS_PGID. In the short > > term, just using wait4 would be the simplest and cleanest for us (same > > as all other archs, no extra case to deal with), but in the long term > > there may be value in having rusage that can represent more than 68 > > cpu-years spent by a process (seems plausible with large numbers of > > cores). > > Based on the feedback from Linus and Eric, the most likely outcome > at the moment seems to be an extension of waitid() to allow > P_PGID with id=0 like BSD does, and not bring back wait4() or > add P_PROCESS_PGID. > > So far, I don't think anyone has proposed an actual kernel patch. > I was hoping that Eric would do it, but I could also send it if he's > otherwise busy. I'm touching waitid() right now. I can pick this up and put this in there too. Christian