> Date: Sat, 6 Jul 2024 14:47:28 +0200
> From: Jeremie Courreges-Anglas <jca@wxcvbn.org>
> 
> On Thu, Jul 04, 2024 at 08:14:15AM -0600, Theo de Raadt wrote:
> > In glibc, getauxval(3) is a monster API that keeps growing additional
> > heads and tentacles.  Exporting a tiny version of it to userland is
> > worrying.
> 
> Agreed about getauxval.

Not sure what you folks mean with that.  Is the problem that there are
too many AT_xxx constants for which we would not want to add support?
That I do agree with.

So do yout think that adding just the few AT_xxx constants that we
care about would cause too many problems in ports?

> > When the real problem here is a tiny little check to use done only
> > internal to only our libc, and therefore why not use an OpenBSD private
> > interface.
> 
> Indeed we could use a private API for this specific need.  But the
> problem is not just about our libc, ports also want a way to query
> hardware capabilities.  We usually have to patch them to use a
> sysctl(2) or just drop the code that detects such capabilities.
> I feel like implementing elf_aux_info(3) should be considered.  Has
> someone already tried that?  If people don't object, that could be a
> todo entry for c2k24.

So elf_aux_info(3) is just getauxval(3) with a somewhat different API.
It is a bit better in the sense that it unambiguously tells you if an
AT_xxx value isn't supported.

Are you less worried about us not implementing all the AT_xxx defines
that FreeBSD has?

I suspect that there is a much smaller number of ports that support
elf_aux_info(3).

> > This means it could be built upon the assumption "this is an
> > openbsd binary", and use a sysctl interface.  After 2 months, there will
> > be only one kind of binary.