Dave Martin <Dave.Martin@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
