Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations
Hi, Le mercredi 16 mai 2018 à 15:20 +0100, Dave Martin a écrit : > There are constraints on defining AT_* auxvec tags that are not > obvious to the casual maintainer of either the global > or the arch-specific headers. This is likely > to lead to mistakes. (I certainly fell foul of it...) > > 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. > > 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. > Some of those AT_* values are described in getauxval(3) man-page: http://man7.org/linux/man-pages/man3/getauxval.3.html https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/g etauxval.3?id=4eae8eb731386d81797d5c30365426722410874e And glibc provides with definitions for almost all AT_*, regardless of the current target architecture: https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h;h=954f3266f7 11ab83996670ea504a17dcf668e061;hb=23158b08a0908f381459f273a984c6fd32836 3cb#l1135 Also, despite not being listed as a reserved namespace by POSIX, one should try to avoid name collision with other AT_ constants, those used with *at() functions (openat(), etc.): - AT_EACCESS - AT_EMPTY_PATH - AT_FDCWD - AT_NO_AUTOMOUNT - AT_REMOVEDIR - AT_STATX_DONT_SYNC - AT_STATX_FORCE_SYNC - AT_STATX_SYNC_AS_STAT - AT_SYMLINK_FOLLOW - AT_SYMLINK_NOFOLLOW http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.htm l#tag_15_02_02 https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fcntl.h;h=3d239e8f0 9f7ce0a3106621be327e1ea4cd1a3e7;hb=23158b08a0908f381459f273a984c6fd3283 63cb#l142 And there's also AT_ANYNET and AT_ANYNODE from ddp (aka. AppleTalk) http://man7.org/linux/man-pages/man7/ddp.7.html Regards. -- Yann Droneaud OPTEYA
Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations
Dave Martin writes: > There are constraints on defining AT_* auxvec tags that are not > obvious to the casual maintainer of either the global > 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. > 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
Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations
On Wed, May 16, 2018 at 04:09:29PM -0700, H. Peter Anvin wrote: > On 05/16/18 08:49, Dave Martin wrote: > > > > Since only contains #defines, it may be enough for arch > > headers to include . > > > > doesn't seem to have any reason to exist at all. If > anyone includes it now, they are Doing It Wrong[TM] since > includes . Sounds good. BTW there probably does need to be a check for kernel-internal use of #ifdef AT_* etc. I saw some instances in arch/um and a few other weird places. They might not matter but there might be code that's indirectly enabled only for certain archs via the AT_* macros. Rich
Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations
On 05/16/18 08:49, Dave Martin wrote: > > Since only contains #defines, it may be enough for arch > headers to include . > doesn't seem to have any reason to exist at all. If anyone includes it now, they are Doing It Wrong[TM] since includes . -hpa
Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations
On Wed, May 16, 2018 at 11:29:13AM -0400, Rich Felker wrote: > On Wed, May 16, 2018 at 03:20:47PM +0100, Dave Martin wrote: > > There are constraints on defining AT_* auxvec tags that are not > > obvious to the casual maintainer of either the global > > or the arch-specific headers. This is likely > > to lead to mistakes. (I certainly fell foul of it...) > > > > 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. > > > > 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. > > On the userspace side (elf.h) all the AT_* constants are in one file. > Why don't we just do the same here and eliminate the > arch/*/include/uapi/asm/auxvec.h files and likewise the need to > manually maintain consistency of the comments about reservations? > > If there are reasons not to do that, I'm not opposed to this patch > as-is. I agree, it would be better to merge them. My concern was that the correct way to get these definitions from userspace is very unclear, so there may be software out there including directly, which would now lack expected definitions. codesearch.debian.net shows no real hits for that, so maybe I'm too paranoid. Since only contains #defines, it may be enough for arch headers to include . Thoughts? Cheers ---Dave
Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations
On Wed, May 16, 2018 at 03:20:47PM +0100, Dave Martin wrote: > There are constraints on defining AT_* auxvec tags that are not > obvious to the casual maintainer of either the global > or the arch-specific headers. This is likely > to lead to mistakes. (I certainly fell foul of it...) > > 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. > > 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. On the userspace side (elf.h) all the AT_* constants are in one file. Why don't we just do the same here and eliminate the arch/*/include/uapi/asm/auxvec.h files and likewise the need to manually maintain consistency of the comments about reservations? If there are reasons not to do that, I'm not opposed to this patch as-is. Rich