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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7187F1F953 for ; Tue, 23 Nov 2021 09:43:23 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 57123385802B for ; Tue, 23 Nov 2021 09:43:22 +0000 (GMT) Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id DF3283858032 for ; Tue, 23 Nov 2021 09:42:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF3283858032 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 92F9B3000346; Tue, 23 Nov 2021 10:42:24 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 833EB425A458; Tue, 23 Nov 2021 10:42:23 +0100 (CET) Message-ID: Subject: Re: [PATCH] elf: add definition for FDO_PACKAGING_METADATA note From: Mark Wielaard To: Florian Weimer , Luca Boccassi Date: Tue, 23 Nov 2021 10:42:23 +0100 In-Reply-To: <8735nousmp.fsf@oldenburg.str.redhat.com> References: <20211121193939.105186-1-luca.boccassi@gmail.com> <87czmsuw2l.fsf@oldenburg.str.redhat.com> <81e0676d26e9f818b79ac31393e2ee613faf9db2.camel@gmail.com> <8735nousmp.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 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: , Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Hi, On Mon, 2021-11-22 at 16:17 +0100, Florian Weimer wrote: > * Luca Boccassi: >=20 > > > Do you have your own registry for this? > >=20 > > Sorry, what do you mean by registry here? A public header? If so, then > > no we do not AFAIK. >=20 > A means for avoiding tag number collisions under the "FDO" namespace. >=20 > glibc only covers a small subset of the note section names. The > Solaris is probably not up to date, and we do not track FreeBSD and > NetBSD at all. (FreeBSD definitely has a bunch of their own tags.) >=20 > We can add it to our own , but the extension mechanism with its > namespace mechanism means that we don't have to. I thing freedesktop.org (FDO) didn't know they could register a new constant under the GNU ELF notes namespace. But it really is just a companion note to NT_GNU_BUILD_ID in the GNU namespace. So it would be really convenient if it gets into the glibc elf.h so that others can pick it up and use it. Cheers, Mark