From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 2DF2A385780C for ; Mon, 25 Jan 2021 14:34:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2DF2A385780C Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-591-OIyZ96ZnN16cfnQHpwehbg-1; Mon, 25 Jan 2021 09:34:47 -0500 X-MC-Unique: OIyZ96ZnN16cfnQHpwehbg-1 Received: by mail-qt1-f198.google.com with SMTP id b23so7318960qto.23 for ; Mon, 25 Jan 2021 06:34:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=l0ovtRl7BoM04iyENR4NqmD8h0NLP2zPXFXQCxJ6ikE=; b=iUEa/0FpBHbhrLYh80Yq0ABudfSIv/ZyZbnA2i4BLisSMuLfk8Ji84/XDxVndebNl3 VAtPdRfdbrlTaospB3bR/ceFVkzHoOqyJuWO0WbxXHkTcq5Pc44neoSRg59Mdi+zaM+a TwM3/gz6yDjILOFPVoRBwWVnWgHh4Oqjc1MqMU9O8crwBixN9CVGkApd+v86tzymohkP qGfeIpyeU1Ke6hr4CBdbtxe4lt8xLR+YF4wbOZ4rAf0ITXFSH6rTEXFi+yDDhUdZjtBX IEgANt8PhdFaQSFKgVThJ7HuMhEu1Pic6AOx+CqsFTZJUZdEKHElWWa9TqIm4IiMRnmB eeig== X-Gm-Message-State: AOAM532280lmRBtTkecTY9XCAkcIlJIa3oPkq/rnQDL2VkZZmfY4szwJ GhZ3MuxhfVJZDABPX15qDw1KmWb1qHw3xwO+hiRU/bXuP08DPijtw/7OfokBp+9PoT/C6E3POtj Xm/+HitTevqcZ8FEFtsEk X-Received: by 2002:a37:65d3:: with SMTP id z202mr1012472qkb.118.1611585286974; Mon, 25 Jan 2021 06:34:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwj+you0krmFYUDXOpEaXY0LJFIUK7BFaYDnRY7JFnfmkk58NYwxwBqit7WW//ZxsHjniSGNw== X-Received: by 2002:a37:65d3:: with SMTP id z202mr1012453qkb.118.1611585286778; Mon, 25 Jan 2021 06:34:46 -0800 (PST) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id c1sm3744379qke.2.2021.01.25.06.34.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Jan 2021 06:34:46 -0800 (PST) Subject: Re: V10 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] From: Carlos O'Donell To: "H.J. Lu" Cc: Florian Weimer , "H.J. Lu via Libc-alpha" , Dave Martin , Joseph Myers References: <20201104165018.GE6882@arm.com> <87lfeyvghf.fsf@mid.deneb.enyo.de> <20201118170434.GF6882@arm.com> <873616va9n.fsf@mid.deneb.enyo.de> <20201118180927.GI6882@arm.com> <87tutkjexc.fsf@mid.deneb.enyo.de> <74ee50ef-948f-b9e7-2525-9cf4ec35b754@redhat.com> Organization: Red Hat Message-ID: <2c156389-6ea8-8f5c-4247-58e66d606076@redhat.com> Date: Mon, 25 Jan 2021 09:34:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <74ee50ef-948f-b9e7-2525-9cf4ec35b754@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Mon, 25 Jan 2021 14:34:53 -0000 On 1/25/21 8:58 AM, Carlos O'Donell wrote: > On 1/22/21 2:41 PM, H.J. Lu wrote: >> On Wed, Jan 20, 2021 at 7:05 AM H.J. Lu wrote: >>> >>> On Wed, Jan 20, 2021 at 6:16 AM Carlos O'Donell wrote: >>>> >>>> On 11/20/20 6:13 PM, H.J. Lu via Libc-alpha wrote: >>>>> On Fri, Nov 20, 2020 at 6:12 AM Florian Weimer wrote: >>>>>> >>>>>> * H. J. Lu: >>>>>> >>>>>>> Can we reach a consensus for _GNU_SOURCE vs _SC_SIGSTKSZ_SOURCE? >>>>>>> >>>>>>> How about we make _GNU_SOURCE to enable _SC_SIGSTKSZ_SOURCE and >>>>>>> check _SC_SIGSTKSZ_SOURCE != 0? If _GNU_SOURCE triggers compilation >>>>>>> error and source codes can't be changed, we can add >>>>>>> -D_SC_SIGSTKSZ_SOURCE=0 to disable _SC_SIGSTKSZ_SOURCE. >>>>>> >>>>>> I think the source code compatibility is much more obscure than the >>>>>> other things we broke quite recently, even without deprecation. Why >>>>>> do we add the complexity in this case? I feel it is disproportional. >>>>> >>>>> Here is the patch with _GNU_SOURCE. Any comments? >>>> >>>> (1) New version of patch. >>>> >>>> This patch no longer compiles due to __cpuid_count errors. >>>> >>>> Could you please update this and post a v9? >>> >>> Fixed. >>> >>>> This is ABI addition for the constants so I want to make sure I review >>>> something that works and is final from your end. >>>> >>>> (2) Kernel definition of constant for AT_MINSIGSTKSZ? >>>> >>>> We don't have a released kernel for x86 with this constant defined? >>>> >>>> The kernel patch was only just updated 5 days ago: >>>> https://sourceware.org/pipermail/libc-alpha/2021-January/121671.html >>>> >>>> Doesn't this mean this patch is inappropriate for glibc 2.33? >>> >>> The new glibc works with the older kernels. In many cases, we >>> use emulation for the older kernels. This patch only uses the >>> existing kernel interface. The kernel patch you referred doesn't >>> add any new interface. It simply uses the existing AT_MINSIGSTKSZ >>> for x86. My patch includes an emulation for the older kernels. I >>> think my patch is appropriate for glibc 2.33. >>> >>> Here is the updated patc. >>> >>> Thanks. >> >> Another rebase. > > This change looks good to me. > > We add two new constants _SC_MINSIGSTKSZ and _SC_SIGSTKSZ. > > We document them as constants to sysconf(). > > We document _SC_SIGSTKSZ_SOURCE as the way to request this change. > > We document this is part of _GNU_SOURCE. > > This may break application builds and may need to be worked around if > the application expected static allocation and need to switch to dynamic > allocation of a constant at runtime. This kind of change may not always > be easy to architect, but should be possible with an early constructor. > > Tested on i686 and x86_64 and all pass. > > Tested-by: Carlos O'Donell > Reviewed-by: Carlos O'Donell This was discussed on the weekly patch review meeting. HJ and I agreed we would delay this until 2.34 opens. Likewise the deprecation. I will add a NEWS item that we are going to do this deprecation. -- Cheers, Carlos.