public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PING][PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries
       [not found] <fd879f60-3f0b-48d1-bfa1-6d337768207e@linux.ibm.com>
@ 2023-10-17 23:14 ` Peter Bergner
  2023-10-18 16:22   ` Szabolcs Nagy
  0 siblings, 1 reply; 2+ messages in thread
From: Peter Bergner @ 2023-10-17 23:14 UTC (permalink / raw)
  To: linux-api, linux-arch, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org
  Cc: Nicholas Piggin, Michael Ellerman, Segher Boessenkool,
	GNU C Library

CCing linux-kernel for more exposure.

PING.  I'm waiting on a reply from anyone on the kernel side of things
to see whether they have an issue with reserving values for AT_HWCAP3
and AT_HWCAP4.  

I'll note reviews from the GLIBC camp did not have an issue with the below patch.

Thanks.

Peter


On 9/26/23 5:02 PM, 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.
> 
> 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 <bergner@linux.ibm.com>
> ---
>  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 */
>  


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PING][PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries
  2023-10-17 23:14 ` [PING][PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries Peter Bergner
@ 2023-10-18 16:22   ` Szabolcs Nagy
  0 siblings, 0 replies; 2+ messages in thread
From: Szabolcs Nagy @ 2023-10-18 16:22 UTC (permalink / raw)
  To: Peter Bergner, linux-api, linux-arch,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
  Cc: Nicholas Piggin, Michael Ellerman, Segher Boessenkool,
	GNU C Library

The 10/17/2023 18:14, Peter Bergner wrote:
> CCing linux-kernel for more exposure.
> 
> PING.  I'm waiting on a reply from anyone on the kernel side of things
> to see whether they have an issue with reserving values for AT_HWCAP3
> and AT_HWCAP4.  
> 
> I'll note reviews from the GLIBC camp did not have an issue with the below patch.

fwiw, aarch64 is quickly filling up AT_HWCAP2 so this will be
useful for arm64 too eventually, but we are not in a hurry.

> > +#define AT_HWCAP3 29	/* extension of AT_HWCAP */
> > +#define AT_HWCAP4 30	/* extension of AT_HWCAP */

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-10-18 16:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <fd879f60-3f0b-48d1-bfa1-6d337768207e@linux.ibm.com>
2023-10-17 23:14 ` [PING][PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries Peter Bergner
2023-10-18 16:22   ` Szabolcs Nagy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox