From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 13D09385700E for ; Wed, 18 Nov 2020 17:04:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 13D09385700E Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CA6231396; Wed, 18 Nov 2020 09:04:38 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3FD693F718; Wed, 18 Nov 2020 09:04:38 -0800 (PST) Date: Wed, 18 Nov 2020 17:04:34 +0000 From: Dave Martin To: Florian Weimer Cc: "H.J. Lu via Libc-alpha" , Joseph Myers Subject: Re: PING: V7 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] Message-ID: <20201118170434.GF6882@arm.com> References: <20201104165018.GE6882@arm.com> <87lfeyvghf.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lfeyvghf.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 17:04:40 -0000 On Wed, Nov 18, 2020 at 04:20:44PM +0100, Florian Weimer wrote: > * H. J. Lu via Libc-alpha: > > > On Wed, Nov 18, 2020 at 7:13 AM Zack Weinberg wrote: > >> > >> On Wed, Nov 18, 2020 at 9:40 AM H.J. Lu wrote: > >> > On Wed, Nov 18, 2020 at 6:26 AM Zack Weinberg wrote: > >> > > > >> > > On Wed, Nov 18, 2020 at 9:14 AM H.J. Lu via Libc-alpha > >> > > wrote: > >> > > > > >> > > > If there are no more comments, I will check in it together with > >> > > > > >> > > > https://sourceware.org/pipermail/libc-alpha/2020-October/118707.html > >> > > > > >> > > > on Friday, Nov 20. > >> > > > >> > > I don't think you have consensus for this ABI-breaking change, and I > >> > > *certainly* don't think you should check it in without positive > >> > > agreement from at least one other person. > >> > > > >> > > >> > My patch adds _SC_SIGSTKSZ_SOURCE. There are no changes > >> > unless _SC_SIGSTKSZ_SOURCE is defined. > >> > >> OK, but do we have consensus on adding a new _*_SOURCE macro and a new > >> sysconf parameter ahead of their adoption by POSIX? This is not a > > > > This is what Dave and I came up with. This approach doesn't change ABI > > unless it is requested by developers. > > Did you mean ABI? > > I think we should use _GNU_SOURCE. We can add another feature macro if > it's adopted by POSIX. Having _GNU_SOURCE enable this feature will break existing source code. It probably should go under _GNU_SOURCE in the long term, but is there usually a transitional period when the change is opt-in via some feature macro? Otherwise, it feels like we would have a chicken-and-egg problem, with nobody wanting to be the first adopter. And also, what, if anything, should be done about the ucontext API? The signal frame on a couple of arches now overruns the original mcontext_t definition. Ucontext seems to be in quite a broken state and is hard to fix because of the lack of extensibility in the design. Signals have also diverged from setcontext() etc. -- some arches don't even encode the same data in there, or put things in the same places between the two APIs. I have some thoughts on what a better interface might look like -- basically separating the signal ucontext_t type from the setcontext()/ getcontext() etc. type, and providing accessors for the architectural register state rather than just having a fixed struct definition for mcontext_t. But, there also may not be a lot of appetite for such a change, and I can't see how it could be backwards compatible. I can elaborate if people think it's worth discussing. Cheers ---Dave