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

From: Ryan Arnold <rsa at us dot ibm dot com>
To: Mike Frysinger <vapier at gentoo dot org>
Cc: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, libc-alpha at sourceware dot org, rth at twiddle dot net, Steven Munroe<sjmunroe at us dot ibm dot com>
Date: Wed, 17 Oct 2012 23:42:52 -0500
Subject: Re: [RFC] Expanding the hwcap
References: <1350425312.25040.6342.camel@localhost.localdomain> <201210170227.56319.vapier@gentoo.org> <1350457846.4678.83.camel@pasglop> <201210171639.16727.vapier@gentoo.org>
Reply-to: rsa at us dot ibm dot com

On Wed, 2012-10-17 at 16:39 -0400, Mike Frysinger wrote:
> 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.

I'm not sure I understand the situation entirely from the kernel
perspective, but I believe that the cpu_spec.cpu_user_features can't
exceed 32-bits on PowerPC32 and to maintain parity with PowerPC64 we
only use the low 32-bits there as well, hence the need for two fields in
the kernel as well.

Ryan

Follow-Ups:
- Re: [RFC] Expanding the hwcap
  - From: Benjamin Herrenschmidt

References:
- [RFC] Expanding the hwcap
  - From: Ryan Arnold
- Re: [RFC] Expanding the hwcap
  - From: Mike Frysinger
- Re: [RFC] Expanding the hwcap
  - From: Benjamin Herrenschmidt
- Re: [RFC] Expanding the hwcap
  - From: Mike Frysinger

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