Re: [PATCH v10 1/3] arm64: Implement archrandom.h for ARMv8.5-RNG
From: Richard Henderson <richard.henderson@linaro.org>
Date: 2020-01-16 00:23:52
On 1/15/20 4:26 AM, Catalin Marinas wrote:
On Wed, Jan 15, 2020 at 11:07:20AM +0000, Mark Brown wrote:quoted
On Wed, Jan 15, 2020 at 10:24:21AM +0100, Ard Biesheuvel wrote:quoted
On Wed, 15 Jan 2020 at 10:16, Will Deacon [off-list ref] wrote:quoted
quoted
I see your argument, but I was just going on the side of consistency because we're continuing to expose other features as HWCAPs when the capability is just a proxy for the cpuid field. I was in favour of stopping the addition of such HWCAPs years ago, but I couldn't convince Catalin ;)quoted
quoted
The way I see it, we'll soon run out of HWCAP2 bits and then we'll have our hand forced.quoted
I don't have a strong opinion either way.Me either, or at least not enough to object to doing it - Will? Catalin?Until the ifunc resolver can work with CPUID, I think we should keep adding HWCAPn bits. We can revisit this with the toolchain people before introducing HWCAP3.
Why would the ifunc resolver not be able to use HWCAP_CPUID? The first argument to the ifunc resolver, apparently since the beginning of time (2013-11-25 7520ff8c744a), AT_HWCAP has been passed directly as the first argument. That means HWCAP_CPUID, present in AT_HWCAP, can always be tested directly. At which point one can access architected registers, with no dynamic linker relocations, to make further decisions. Admittedly there's a trap to the OS involved, but there is *far* too much info in those registers to copy everything to HWCAPn. The current state of affairs, as of glibc-2.30, is that the first argument is augmented to include a _IFUNC_ARG_HWCAP bit, which indicates the presence of a second argument, a pointer to struct __ifunc_arg_t. This struct does include a size field, allowing the struct to be extended in future. That said, speaking as a toolchain guy, you should conserve HWCAP2 bits so that, by preference, you do not need to introduce AT_HWCAP3. Or at least delay adding it. r~ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel