From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id BBEB138582BD for ; Wed, 27 Sep 2023 16:03:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBEB138582BD Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1c60cec8041so54244865ad.3 for ; Wed, 27 Sep 2023 09:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1695830588; x=1696435388; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=cc32aBSxiKmB7YJYiVYNyRkEBllulbgFY+PbuERINks=; b=TwHaln8g7ZkH26J3D2Gg66A7sjmS9sA7a9epCqOvu7qqsHrciKm6rnNenYaxr3WiuD AUGFnGEU2SE0RsXysomrB0jq5/Rhj7D2wjbrggL/TraeLJIywlpakM970DbfeYMUns99 nt4Y6odXRJK8hqj8av2mGS70lSa2o73InnfDYfffg7DpN4xJXHYPdqZm2zOvN3WupmTS yVLX5z0mVAWMJxNhOhgv+SO4HW1xJxrtnBUX/I5sGZd0KDQ3ClzkPL3K9qaAOer1yef0 vb9ceYeH3oa3Xiq6zlb4fJHnCS6NV30XcfYHgh5OBhmDuLGrz84W8xjTChLLYiNvhrEA u7fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695830588; x=1696435388; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cc32aBSxiKmB7YJYiVYNyRkEBllulbgFY+PbuERINks=; b=Xz3MnDirMnH3oqRmulu0o0qstW14V990/ZLm4qRWOCObrcbZ/6RqeUSyrVEPlQjo6q uXHLT+blSF+fngzydMglq/MLIHYU3fwHF4CzD7KjrQPaupjHjHuT9os87ogv0yytr5zb 56wPukKZD7Gbsd0fScqxgusG39zXmv46cBJRrl4NidSDQHg2m4EOXpUPx7wyLew+Dvod vFNTJeWO4Z1UZ7/2wL1WXlH9djbyQ0XtA3toYcwghL6RvjIPhU6wFp75ZRtOjZ6Qs0Il chljJ6/sbdE3JhVRY5tojfaCsE6oZ1N3EAhqjgbrIftVxPIV5Cp+e4hCYaazRMrP1K6T iOmw== X-Gm-Message-State: AOJu0YzK6nFRuA4jS/KPtaC8Jsq8+IhMj/OlpXXi2kWwfjvPbhsYuv60 G249VaKmgl7UhTvbQwTcsiKfzg== X-Google-Smtp-Source: AGHT+IHxY4DW2OVHGZCmyyi4u1VB9W8yCdtBLbEwI6vaIqaWlrij8p9kxEZXh5NCY69eQYN3+gKd+Q== X-Received: by 2002:a17:902:b414:b0:1c3:52ed:18f9 with SMTP id x20-20020a170902b41400b001c352ed18f9mr1953496plr.62.1695830587598; Wed, 27 Sep 2023 09:03:07 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:6eb0:6d4f:92fe:5e4e:27d3? ([2804:1b3:a7c1:6eb0:6d4f:92fe:5e4e:27d3]) by smtp.gmail.com with ESMTPSA id az11-20020a170902a58b00b001c5bcc9d916sm13274132plb.176.2023.09.27.09.03.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Sep 2023 09:03:06 -0700 (PDT) Message-ID: <97eb2099-23c2-4921-89ac-9523226ad221@linaro.org> Date: Wed, 27 Sep 2023 13:03:02 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries Content-Language: en-US To: Peter Bergner , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" Cc: Nicholas Piggin , Michael Ellerman , Segher Boessenkool , GNU C Library References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 26/09/23 19:02, Peter Bergner wrote: > The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast > access by our __builtin_cpu_supports built-in function. The TCB space for > the HWCAP entries - which are created in pairs - is an ABI extension, so > waiting to create the space for HWCAP3 and HWCAP4 until we need them is > problematical, given distro unwillingness to apply ABI modifying patches > to distro point releases. Define AT_HWCAP3 and AT_HWCAP4 in the generic > uapi header so they can be used in GLIBC to reserve space in the powerpc > TCB for their future use. This is different than previously exported auxv, where each AT_* constant would have a auxv entry. On glibc it would require changing _dl_parse_auxv to iterate over the auxv_values to find AT_HWCAP3/AT_HWCAP4 (not ideal, but doable). Wouldn't be better to always export it on fs/binfmt_elf.c, along with all the machinery to setup it (ELF_HWCAP3, etc), along with proper documentation? > > I scanned both the Linux and GLIBC source codes looking for unused AT_* > values and 29 and 30 did not seem to be used, so they are what I went > with. If anyone sees a problem with using those specific values, I'm > amenable to using other values, just let me know what would be better. > > Peter > > > Signed-off-by: Peter Bergner > --- > include/uapi/linux/auxvec.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h > index 6991c4b8ab18..cc61cb9b3e9a 100644 > --- a/include/uapi/linux/auxvec.h > +++ b/include/uapi/linux/auxvec.h > @@ -32,6 +32,8 @@ > #define AT_HWCAP2 26 /* extension of AT_HWCAP */ > #define AT_RSEQ_FEATURE_SIZE 27 /* rseq supported feature size */ > #define AT_RSEQ_ALIGN 28 /* rseq allocation alignment */ > +#define AT_HWCAP3 29 /* extension of AT_HWCAP */ > +#define AT_HWCAP4 30 /* extension of AT_HWCAP */ > > #define AT_EXECFN 31 /* filename of program */ >