This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Expanding the hwcap
- From: Richard Henderson <rth at twiddle dot net>
- To: rsa at us dot ibm dot com
- Cc: libc-alpha at sourceware dot org, Benjamin Herrenschmidt <benh at kernel dot crashing dot org>,Steven Munroe <sjmunroe at us dot ibm dot com>
- Date: Wed, 17 Oct 2012 11:20:25 +1000
- Subject: Re: [RFC] Expanding the hwcap
- References: <1350425312.25040.6342.camel@localhost.localdomain>
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~