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

[Catalin Marinas]

On Wed, Jun 29, 2022 at 11:01:43AM +0100, Szabolcs Nagy wrote:
> The 06/28/2022 16:06, Mark Brown wrote:
> > 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:
> > > > +/* 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?  
> 
> only the top two bits of AT_HWCAP are reserved for glibc.
> (bits of AT_HWCAP2 are not reserved.)
> 
> we did the 32bit limit because of ilp32 and i requested to
> keep following that.
> 
> there is no precedent for using more than 32bit AT_HWCAP nor
> precedent for using AT_HWCAP3.
[...]
> - start using top bits of AT_HWCAP2 but not of AT_HWCAP.
>   (this is the least amount of work for now)

That's a bit more appealing to me in the short term, though we may still
end up with AT_HWCAP3 at some point. Is anyone still thinking seriously
about ILP32?

-- 
Catalin