[PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

On 20 January 2014 19:55, Nicolas Pitre [off-list ref] wrote:

On Mon, 20 Jan 2014, Ard Biesheuvel wrote:

quoted

On 20 January 2014 19:17, Nicolas Pitre [off-list ref] wrote:

quoted

On Mon, 20 Jan 2014, Ard Biesheuvel wrote:

quoted

Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
whole value, not just the bits whose meaning was known to glibc at the
time.
So if desired, a program can interpret AT_HWCAP itself.

AT_HWCAP2 is completely new, so you won't be able to retrieve it using
getauxval() on an older libc.

I agree.  And I don't dispute the bit placement choice either.

Still, an old glibc calling getauxval(AT_HWCAP) should already be
prepared to receive and rightfully ignore those bits it didn't know the
meaning of at the time.  So "preserving some future extensions in HWCAP
for older glibc" as a justification makes little sense to me... unless
I'm missing something?

Even if applications interpret those bits themselves, supposing they
still need to be linked against an old glibc, then why would
yet-to-be-defined future extensions be more important to be signaled
using the lower 32 bits than the extensions you propose?  That is what I
don't get.

In the general case, you are quite right.

In this particular case, the extensions for which I am adding the
feature bits are not supported on any hardware currently known or
supported by the ARM port. At this time, the only known CPUs
supporting these extensions are ARMv8 CPUs executing in 32-bit
compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
execution state using previously unallocated opcodes)

So?

quoted

So the only reason (currently) for adding these feature bits to the
ARM port is to align with the ARMv8 32-bit compat mode so that a
32-bit userland requires no knowledge about whether its 32-bit
execution environment is hosted by an ARM or an arm64 kernel. In the
future, ARMv8 32-bit only CPUs may well turn up that support these
extensions as well.

I agree with all you've said so far.  But that doesn't answer my
question.

And my unanswered question isn't that important either.

Quoting Russell:

On 18 December 2013 12:42, Russell King - ARM Linux
[off-list ref] wrote:

The point is that they'll never appear on an ARMv7 implementation because
they're not part of the ARMv7 architecture.  I see no point in needlessly
polluting ARM32 with ARM64 stuff - in exactly the same way that you see
no point in polluting ARM64 with ARM32 stuff.

So, frankly, find a different way to this.  We don't need to needlessly
waste HWCAP bits on ARM32.

So my idea was to use HWCAP2 bits instead ...

-- 
Ard.