This is the mail archive of the
mailing list for the glibc project.
[RFC] Expanding the hwcap
- From: Ryan Arnold <rsa at us dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Cc: rth at twiddle dot net, Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, Steven Munroe <sjmunroe at us dot ibm dot com>
- Date: Tue, 16 Oct 2012 17:08:32 -0500
- Subject: [RFC] Expanding the hwcap
- Reply-to: rsa at us dot ibm dot com
Before wasting time working on a patch that may be rejected for any
number of alternatives, I've decided to gather comments on a proposed
method for exporting additional hwcap information from the Linux Kernel
to GLIBC (and ultimately user space through the new interfaces provided
by Richard Henderson).
The Power Architecture doesn't have a dedicated register to store the
hwcap bits so must rely upon the hwcap field of the auxv. Unfortunately
we're out of bits on PowerPC due to the word size in powerpc32. And
since there's parity between the hwcap bits on powerpc64, we're out of
bits there as well since we can't use the high 32-bits.
I've chatted with some of the Linux kernel developers and there have
been a number of proposed ideas.
The simplest method would be to export another word from the kernel
named hwcap2. This would create a second hwcap entry in the
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.
Ryan S. Arnold
IBM Linux Technology Center