[PATCH v2 1/4] arm64/cpufeature: Store elf_hwcaps as an array rather than unsigned long

[Mark Brown]

On Tue, Jun 28, 2022 at 03:21:25PM +0100, Will Deacon wrote:
> On Mon, Jun 20, 2022 at 01:54:48PM +0100, Mark Brown wrote:

> I would like to see an Ack on this series from the libc side (i.e.
> Szabolcs) before we extend the ABI. Have any other architectures used

Me too.

> HWCAP3?

No, hence needing to add it.

> > +/* Note that bits 62 and 63 of each AT_HWCAP are reserved */

> Can you expand a bit on this comment, please? It's not clear who has
> reserved those bits (e.g. kernel or userspace) and why having two bit
> reserved means we are limited to 32 instead of 62 bits.

It's also not clear to me why they're reserved, I didn't manage to dig
far enough into the history to figure that out - I believe it's a glibc
thing, or at least something glibc now expects.  Indeed I can't
immediately dig up the specific reference now.  Szabolcs?  

> >  /* Kernel representation of AT_HWCAP and AT_HWCAP2 */
> > -static unsigned long elf_hwcap __read_mostly;
> > +static unsigned long elf_hwcap[MAX_CPU_FEATURES / CPU_FEATURES_PER_HWCAP] __read_mostly;

> I can't help but think this would be neater as an explicit bitmap
> (i.e. DECLARE_BITMAP).

IIRC my thinking there was that the need to chop the bitmap up into
chunks that aren't word sized that made me not use that - the code to
read and write is a lot simpler if hwcapN is a single array element.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220628/85d9eebe/attachment.sig>