Re: [ARM] bits/hwcap.h update

[Phil Blundell <pb at pbcl dot net>]

On Tue, 2016-12-13 at 09:39 +0000, Szabolcs Nagy wrote:
> 
> they are always linux specific because linux can
> define new ones (if there is space) so the question
> is if there is a reason now to invent new names
> instead of exposing linux uapi names.

Using the kernel names would make it impossible (or at least awkward)
to access both the arm and arm64 definitions simultaneously, since the
kernel uses the same names for both but the numeric values are
different.  In analogous cases having to do with ELF for example, the
macro names are all namespaced by architecture so they don't collide. 
But I can't immediately think of any realistic situation in which one
would want to do that for hwcaps, so it probably doesn't matter very
much.

Conversely, we clearly can't just drop the existing glibc names and I
am not all that thrilled about glibc having to maintain two names for
all these macros in perpetuity.  And it's not entirely obvious to me
that there is all that much real benefit from having the names be
aligned, so I think I would be inclined to just leave it alone.

I suppose one could argue that the glibc names are "better" and if
alignment is desirable then the kernel ought to change (and it might
even be possible to do that without maintaining backwards
compatibility, given that I suspect most applications are in practice
using the definitions from glibc rather than the ones from the
kernel).  But I imagine any such suggestion would meet with resistance
from the kernel folks.

p.