Dave Martin [off-list ref] writes:

There are constraints on defining AT_* auxvec tags that are not
obvious to the casual maintainer of either the global
<uapi/linux/auxvec.h> or the arch-specific headers.  This is likely
to lead to mistakes.  (I certainly fell foul of it...)

Thanks for cleaning this up.

It looks like us (powerpc) / me is the main offender here.

My excuse is it was glibc folk who asked us to add all those new AT_
entries in the first place. </buckpassing>

For the benefit of future maintainers, this patch collects the
relevant information in one place, documenting how the namespace
needs to be managed, and noting all the values currently in use.

Maintaining a global list may result in some merge conflicts, but
AT_* values are not added frequently.  I'm open to suggestions on
the best approach.

Yeah I agree with Rich that having a global list would be best. That is
the most reliable to make people think twice about adding new entries.

I also assume that values 38 and 39 may have been used for
historical purposes, such as an architecture that is no longer
supported.  If they have definitely never been used for anything,
they could be removed from the "reserved" list.

I don't know why we added the new entries starting at 40, maybe Ben
remembers. Quite likely it was just an accident.

I don't see any sign of 38 or 39 in glibc history.

cheers