From: Jeremie Courreges-Anglas Subject: Re: arm64 LSE support in userland: introduce elf_aux_info? To: j@bitminer.ca Cc: Tech Date: Fri, 12 Jul 2024 11:22:17 +0200 On Thu, Jul 11, 2024 at 09:17:44AM -0400, j@bitminer.ca wrote: > > > Feedback from other porters would be welcome. > > Well I'm sure you are getting a lot from @sthen and others offlist, > here is my input regarding getauxval: This diff was really about elf_aux_info. > 1) you are filtering the truth and providing a BSD-specific set of > "interpretations" of the truth. > > The "truth" is the contents of CPU-capability registers. Why provide > an opinionated interpretation of these, instead of just readable > copies? There are features we want to hide from userland and some features that we want to expose. Among the latter, some features may require kernel support, and exposing those without kernel support would be wrong. What is currently exposed on arm64 through the sysctl(2) API should already be correct and useful. [...] > Look at the patch suggested by @jca in elf.h for HWCAP2, there is > only 19 bits left unused. How many years of ARM architecture > evolution will that last? Three? Four? The solution to that problem appears to be: use HWCAP_CPUID to tell whether you can call cpu-specific cpuid instructions. Those would have to be emulated and sanitized by the kernel on some architectures. See Mark's previous mails. > 3) OK, I'm sounding grumpy, sorry. > > Here is my solution: provide readable copies of CPU capability > registers. Period. > > Do a getauxval if you want, but make the actual truth available to > the code as simple copies of the registers. And of course in sysctl > (mostly done) as well as a libc equivalent. Code does not write itself. Do send grumpy comments if you want, but make sure you also send useful reports and diffs for stuff you care about. That will be much more effective than using an imperative mood. ;) -- jca