From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 29A0F38582AE for ; Thu, 4 Aug 2022 20:04:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29A0F38582AE Received: by mail-pg1-x52e.google.com with SMTP id q16so823537pgq.6 for ; Thu, 04 Aug 2022 13:04:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=0JbLYN6KkkpVpYk4dVW/VXZQclopART/a12TLn/Ztgs=; b=Vv+rshOKBH1iHDynMhFN9X/vxIpzpHcOpbp3qEFdKYVxX0rlAtFtcZel1SWcQUvfdV qLvwBM/uP27cBPtHksZxkYR3RJdR1r7hFp72jx7KiBpp8aH6fN2CZD6TavlFOuc9rs6F klq5v4fBcL7JFHU5L4O/43VrAcVhYCuQE8jtcuZczTc4zJ3bQk7aPgFMDGqwjAxQcI8n WPn6jj0bd5n0FKDnNU0nu880w7UXFGtpyQK2ZMg700TlZOLJQsmon+XX/UqqpMqqo18f EHU5QL7IT/dMDLPVJirrlm9uuPDyWP1HYRa+uIubWcouRyn543Pmlwql1rX8j7KUTVzb ALgg== X-Gm-Message-State: ACgBeo1bGwWnqatDxHh9H+nzn7DGikoGHTbiIPTPMcGliFomcecrQHBO S1HcAnZ3Y/RuH+Qq8IrEOTequA== X-Google-Smtp-Source: AA6agR4wbmKso0BmlGP47YZo5A5oh4Z4Natv91jFMr8lVz1kKZEUkVq6zScBwnQ7WAkWv7qATktF3Q== X-Received: by 2002:a63:1246:0:b0:41a:58f:9fee with SMTP id 6-20020a631246000000b0041a058f9feemr2823584pgs.413.1659643487135; Thu, 04 Aug 2022 13:04:47 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:89fa:4039:15f3:a5b]) by smtp.gmail.com with ESMTPSA id x17-20020aa79571000000b0052dc9d8574dsm1382870pfq.128.2022.08.04.13.04.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Aug 2022 13:04:46 -0700 (PDT) Date: Thu, 4 Aug 2022 13:04:42 -0700 From: Fangrui Song To: Carlos O'Donell Cc: Adhemerval Zanella Netto , Cary Coutant , Florian Weimer , libc-alpha Subject: Re: [PATCH] elf.h: Add ELFCOMPRESS_ZSTD Message-ID: <20220804200442.sypcy42jyqmlmoqs@google.com> References: <20220708233233.2554110-1-maskray@google.com> <871qus8cuw.fsf@oldenburg.str.redhat.com> <20220722230837.qea3d33gvji5kxtl@google.com> <8c2e6f15-c08c-9872-3b53-f514ead5692f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <8c2e6f15-c08c-9872-3b53-f514ead5692f@redhat.com> X-Spam-Status: No, score=-20.0 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, FSL_HELO_FAKE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 04 Aug 2022 20:04:51 -0000 On 2022-07-29, Carlos O'Donell wrote: >On 7/26/22 16:30, Fangrui Song wrote: >> On Tue, Jul 26, 2022 at 1:24 PM Adhemerval Zanella Netto >> wrote: >>> >>> >>> >>> On 22/07/22 20:08, Fangrui Song via Libc-alpha wrote: >>>> On 2022-07-18, Carlos O'Donell via Libc-alpha wrote: >>>>> On 7/11/22 00:58, Florian Weimer via Libc-alpha wrote: >>>>>> * Fangrui Song via Libc-alpha: >>>>>> >>>>>>> I wish that the macro definition can catch up the upcoming >>>>>>> https://sourceware.org/glibc/wiki/Release/2.36 [1], so that >>>>>>> projects can expect the value ELFCOMPRESS_ZSTD from elf.h. >>>>>>> The projects may choose to define the macro themselves, >>>>>>> but having the definition in an earlier release seems a good idea >>>>>>> anyway, and it the glibc definition makes it clearer ELFCOMPRESS_ZSTD >>>>>>> is standard and vendors can start adding support. >>>>>>> >>>>>>> [1]: https://sourceware.org/pipermail/libc-alpha/2022-July/140352.html >>>>>>> ("Release of glibc 2.36 in 1 month! Please add blockers and desirable for release.") >>>>>> >>>>>> This looks quite backportable to me, so it should not be a release >>>>>> blocker. It's only a blocker if we apply the patch today, then we'd >>>>>> have to wait until the gABI assignment actually happens as expected. >>>>> >>>>> Agreed. This is a NACK from me as the RM until the gABI assignment happens. >>>>> >>>> >>>> Cary has accepted this value: https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ >>>> (Thanks!) >>>> >>>> Ed Maste from FreeBSD wants to define this in FreeBSD. >>>> >>>> Shall we define it for glibc as well? :) >>> >>> I think this is ok, we are already fixing bad designs so we most likely need >>> more time for testing. >> >> Thanks. Now that it is approved, the commit message can be changed to >> the following if you want to push it to the 2.36 release branch. >> >> elf.h: Add ELFCOMPRESS_ZSTD >> >> From the approved generic ABI proposal >> https://groups.google.com/g/generic-abi/c/satyPkuMisk >> ("Add new ch_type value: ELFCOMPRESS_ZSTD"). > >Cary, > >Is there a public repo that I can use to cross-check the glibc value with >the accepted ELF gABI value? > >A public repo would make the process of adding matching constants >easier because I could review what went into the public repository. > >Fangrui, > >Just for clarity, I don't consider this a release blocker for 2.36. Cary pushed a similar change to binutils-gdb https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=03d0ae791f7dca2006b924e90ee4e4944b848260 Cary mentioned it on the musl mailing list https://www.openwall.com/lists/musl/2022/08/03/3 "Yes, this is officially approved."