Re: [ARM] bits/hwcap.h update

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 12/12/16 20:09, Phil Blundell wrote:
> On Mon, 2016-12-12 at 17:43 +0000, Szabolcs Nagy wrote:
>>
> I can propose a patch, however it seems the glibc names for HWCAP
>> bits are different than the linux names: HWCAP_ARM_.. vs HWCAP_..
>>
>> These are linux specific flags as noted in
>> https://sourceware.org/ml/libc-ports/2012-08/msg00069.html
>> so i'm not sure why the difference.
>>
>> Does anybody know the reason?
> 
> No particular reason that I can remember.  At the time the original ARM
> hwcap bits were added to glibc, I think the naming probably followed
> the pattern that most other architectures were using in glibc, e.g.
> HWCAP_386_xx, HWCAP_SPARC_xx.  The ARM kernel is a bit of an oddity in
> defining just plain HWCAP_xx without any architecture mentioned in the
> name, and I suppose it seemed more important at the time to have a
> consistent naming convention for the user-visible headers in glibc than

on sh the name is CPU_HAS_*, on powerpc it's
PPC_FEATURE_*, so i don't think arm is an oddity
here, these are target specific definitions.

> to match the naming used in the kernel.  Particularly because the names
> of these bits predated the existence of the uapi/ headers by about a
> decade, and at the time they were added the kernel definitions were
> buried in <asm/elf.h> or some such place that user-space programs were
> unlikely ever to see.

i see.

glibc now exposes getauxval (and ifunc with hwcap
arg) so the user needs these bits.

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.