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: [RFC] Expanding the hwcap


On 2012-10-17 08:08, Ryan Arnold wrote:
> The simplest method would be to export another word from the kernel
> named hwcap2.  This would create a second hwcap entry in the
> rtld_global_ro structure.
> 
> In GLIBC we could copy these bits up to the high 32-bits of the existing
> 64-bit hwcap (uint64) and continue to access the existing hwcap via the
> GLRO macros.  This would of course eliminate parity between the kernel
> hwcap definitions and those in GLIBC (exported via hwcap.h).
> 
> Or simply use the existing GLRO macros and make sure we know which hwcap
> word the individual bits reside in when we test for them.  This would
> complicate the hwcap interfaces that Richard Henderson recently added.
> 
> An alternative is to create a hwcap vector (Ben H. has suggested perhaps
> this could exist in the VDSO) and then rtld_global_ro will contain a
> pointer to the hwcap vector.  This seems a bit excessive considering how
> long it took to fill up the first hwcap.  It's also undesirable in that
> it'd be more expensive to do runtime hwcap checks.
> 
> Thoughts?

Unless IBM intends to go hog-wild with extensions over the next years,
I see no reason to do anything but hwcap2, using the correct glro word
with the correct HWCAP2_* macro.


r~


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