This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ARM] bits/hwcap.h update


On 13/12/16 11:28, Phil Blundell wrote:
> 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.
> 

other platforms (e.g. bionic) don't have the glibc
names (which are not documented anyway) and we need
to sync new hwcap names from the kernel (HWCAP2_*)
and it does not seem right to keep inventing new
names for those.

sh4 should also expose the CPU_HAS_* definitions,
powerpc already exposes PPC_FEATURE* in bits/hwcap.h.

(when i added arm HWCAP bits to musl i used the
linux names, beacuse i didn't know glibc invented
something else, i assume other implementors do the
same: go makes a subset of HWCAPs available using
the linux names)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]