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 9BAD81F45A for ; Wed, 14 Aug 2019 16:13:59 +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=ntuA mdPnFDiBNsubcCNheZRLWweSHtdMoCUb5cgLueEUE7e5dQCOCnlAVOSSejq4jb0g pZyosku1Jth8GkYsmKhl8TqcR91sdc6G6tp+vjzCoWgp/ydkA95batu7LanYvJJo 2SlSFA1Jj/eiMtJQA9LaemJmN6TGY24rlE/NpsY= 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=+fn9p2wNoB oZgCH3ZEf787pKV5g=; b=MWb+A9fXPtbcCnjN+t4XO3qpmfucioNx9ex2+ZJCQ4 uvNoUjDmYsJ9FY4NxmEG/uL6fCEiimzcAC2pkztkZGLefd7/iFo/WK6hpu5iqlqG 8zWbl3lxPsZGC17W/cS/9+tq59V+/XDXOq1hwcs48cMM1B878CpBgwM9iffam4CU Y= Received: (qmail 59249 invoked by alias); 14 Aug 2019 16:13:57 -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 59239 invoked by uid 89); 14 Aug 2019 16:13:56 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: youngberry.canonical.com Date: Wed, 14 Aug 2019 18:13:51 +0200 From: Christian Brauner To: Rich Felker Cc: linux-kernel@vger.kernel.org, libc-alpha@sourceware.org, oleg@redhat.com, alistair23@gmail.com, ebiederm@xmission.com, arnd@arndb.de, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, fweimer@redhat.com, palmer@sifive.com, macro@wdc.com, zongbox@gmail.com, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, hpa@zytor.com Subject: Re: [PATCH v3 0/1] waitid: process group enhancement Message-ID: <20190814161351.4kbphhapeqejkgg7@wittgenstein> References: <20190814154400.6371-1-christian.brauner@ubuntu.com> <20190814155822.GI9017@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190814155822.GI9017@brightrain.aerifal.cx> User-Agent: NeoMutt/20180716 On Wed, Aug 14, 2019 at 11:58:22AM -0400, Rich Felker wrote: > On Wed, Aug 14, 2019 at 05:43:59PM +0200, Christian Brauner wrote: > > Hey everyone, > > > > This patch adds support for waiting on the current process group by > > specifying waitid(P_PGID, 0, ...) as discussed in [1]. The details why > > we need to do this are in the commit message of [PATCH 1/1] so I won't > > repeat them here. > > > > I've picked this up since the thread has gone stale and parts of > > userspace are actually blocked by this. > > > > Note that the patch has been changed to be more closely aligned with the > > P_PIDFD changes to waitid() I have sitting in my for-next branch (cf. [2]). > > This makes the merge conflict a little simpler and picks up on the > > coding style discussions that guided the P_PIDFD patchset. > > > > There was some desire to get this feature in with 5.3 (cf. [3]). > > But given that this is a new feature for waitid() and for the sake of > > avoiding any merge conflicts I would prefer to land this in the 5.4 > > merge window together with the P_PIDFD changes. > > That makes 5.4 (or later, depending on other stuff) the hard minimum > for RV32 ABI. Is that acceptable? I was under the impression (perhaps > mistaken) that 5.3 was going to be next LTS series which is why I'd > like to have the necessary syscalls for a complete working RV32 > userspace in it. If I'm wrong about that please ignore me. :-) 5.3 is not going to be an LTS and we don't do new features after the merge window is closed anyway. :) Christian