Changes from v1:
- Add Acked-by lines.
The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
access by the __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. 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 through 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. This has received Acked-by's from both GLIBC and Linux kernel
developers and no reservations or Nacks from anyone.
Arnd, we seem to have consensus on the patch below. Is this something
you could take and apply to your tree?
Peter
Signed-off-by: Peter Bergner <[email protected]>
Acked-by: Adhemerval Zanella <[email protected]> (glibc)
Acked-by: Nicholas Piggin <[email protected]> (powerpc)
Acked-by: Szabolcs Nagy <[email protected]> (arm)
---
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 */
--
2.39.3
On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote:
> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
> access by the __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. 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 through 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. This has received Acked-by's from both GLIBC and Linux kernel
> developers and no reservations or Nacks from anyone.
>
> Arnd, we seem to have consensus on the patch below. Is this something
> you could take and apply to your tree?
>
I don't mind taking it, but it may be better to use the
powerpc tree if that is where it's actually being used.
If Michael takes it, please add
Acked-by: Arnd Bergmann <[email protected]>
Arnd
On 2/15/24 2:16 AM, Arnd Bergmann wrote:
> On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote:
>> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
>> access by the __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. 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 through 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. This has received Acked-by's from both GLIBC and Linux kernel
>> developers and no reservations or Nacks from anyone.
>>
>> Arnd, we seem to have consensus on the patch below. Is this something
>> you could take and apply to your tree?
>>
>
> I don't mind taking it, but it may be better to use the
> powerpc tree if that is where it's actually being used.
So this is not a powerpc only patch, but we may be the first arch
to use it. Szabolcs mentioned that aarch64 was pretty quickly filling
up their AT_HWCAP2 and that they will eventually require using AT_HWCAP3
as well. If you still think this should go through the powerpc tree,
I can check on that.
Peter
Peter Bergner <[email protected]> writes:
> On 2/15/24 2:16 AM, Arnd Bergmann wrote:
>> On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote:
>>> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
>>> access by the __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. 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 through 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. This has received Acked-by's from both GLIBC and Linux kernel
>>> developers and no reservations or Nacks from anyone.
>>>
>>> Arnd, we seem to have consensus on the patch below. Is this something
>>> you could take and apply to your tree?
>>>
>>
>> I don't mind taking it, but it may be better to use the
>> powerpc tree if that is where it's actually being used.
>
> So this is not a powerpc only patch, but we may be the first arch
> to use it. Szabolcs mentioned that aarch64 was pretty quickly filling
> up their AT_HWCAP2 and that they will eventually require using AT_HWCAP3
> as well. If you still think this should go through the powerpc tree,
> I can check on that.
I'm happy to take it with Arnd's ack.
I trimmed up the commit message a bit, see below.
cheers
Author: Peter Bergner <[email protected]>
AuthorDate: Wed Feb 14 16:34:06 2024 -0600
Commit: Michael Ellerman <[email protected]>
CommitDate: Fri Feb 16 12:42:59 2024 +1100
uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries
The powerpc toolchain keeps a copy of the HWCAP bit masks in the TCB
for fast access by the __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
they are needed is problematic. 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 through 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.
Signed-off-by: Peter Bergner <[email protected]>
Acked-by: Adhemerval Zanella <[email protected]>
Acked-by: Nicholas Piggin <[email protected]>
Acked-by: Szabolcs Nagy <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/[email protected]
On 2/15/24 7:49 PM, Michael Ellerman wrote:
> Peter Bergner <[email protected]> writes:
>> On 2/15/24 2:16 AM, Arnd Bergmann wrote:
>>> On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote:
>>>> Arnd, we seem to have consensus on the patch below. Is this something
>>>> you could take and apply to your tree?
>>>>
>>>
>>> I don't mind taking it, but it may be better to use the
>>> powerpc tree if that is where it's actually being used.
>>
>> So this is not a powerpc only patch, but we may be the first arch
>> to use it. Szabolcs mentioned that aarch64 was pretty quickly filling
>> up their AT_HWCAP2 and that they will eventually require using AT_HWCAP3
>> as well. If you still think this should go through the powerpc tree,
>> I can check on that.
>
> I'm happy to take it with Arnd's ack.
>
> I trimmed up the commit message a bit, see below.
Perfect. Thanks everyone!
Peter
On Wed, 14 Feb 2024 16:34:06 -0600, Peter Bergner wrote:
> Changes from v1:
> - Add Acked-by lines.
>
> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
> access by the __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. 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.
>
> [...]
Applied to powerpc/next.
[1/1] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries
https://git.kernel.org/powerpc/c/3281366a8e79a512956382885091565db1036b64
cheers