Re: [RFC] Expanding the hwcap

[Mike Frysinger <vapier at gentoo dot org>]

On Wednesday 17 October 2012 03:10:46 Benjamin Herrenschmidt wrote:
> On Wed, 2012-10-17 at 02:27 -0400, Mike Frysinger wrote:
> > On Tuesday 16 October 2012 18:08:32 Ryan Arnold wrote:
> > > 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).
> > 
> > maybe i'm naive, but couldn't you have the kernel declare
> > cpu_spec.cpu_user_features as 64bit and then take care of splitting up
> > ELF_HWCAP into AT_HWCAP and AT_HWCAP2 automatically ?  you could have the
> > 
> > binfmt loader do something like:
> > 	NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> > 	if (sizeof(*elf_info) < sizeof(ELF_HWCAP))
> > 	
> > 		NEW_AUX_ENT(AT_HWCAP2, (ELF_HWCAP) >> (sizeof(*elf_info) * 8));
> > 
> > then the ldso knows that if it sees AT_HWCAP2, it has to manually merge
> > it into the higher bits.
> 
> The kernel side doesn't matter, it's my internal cuisine. The important
> bit is the ABI to glibc, which is the same in both cases :-)

sure.  my point was that we can keep a single hwcap in glibc itself and keep 
the hwcap.h macros the same.  the kernel will maintain a single 64bit value 
internally, take care of splitting it into two (AT_HWCAP & AT_HWCAP2), and 
glibc will take care of merging it back into one thus it only needs one hwcap 
value accessible via GLRO.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.