From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rich Felker Subject: Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations Date: Wed, 16 May 2018 11:29:13 -0400 Message-ID: <20180516152913.GY1392@brightrain.aerifal.cx> References: <1526480447-18185-1-git-send-email-Dave.Martin@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1526480447-18185-1-git-send-email-Dave.Martin@arm.com> Sender: linux-kernel-owner@vger.kernel.org To: Dave Martin Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Michal Simek , Ralf Baechle , James Hogan , Greentime Hu , Vincent Chen , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Palmer Dabbelt , Albert List-Id: linux-arch.vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:54160 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbeEPP3V (ORCPT ); Wed, 16 May 2018 11:29:21 -0400 Date: Wed, 16 May 2018 11:29:13 -0400 From: Rich Felker Subject: Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations Message-ID: <20180516152913.GY1392@brightrain.aerifal.cx> References: <1526480447-18185-1-git-send-email-Dave.Martin@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1526480447-18185-1-git-send-email-Dave.Martin@arm.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dave Martin Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Michal Simek , Ralf Baechle , James Hogan , Greentime Hu , Vincent Chen , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Palmer Dabbelt , Albert Ou , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , "David S. Miller" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Chris Zankel , Max Filippov Message-ID: <20180516152913.ZCzgNItGGtxYdV2Y6os8oKmgn8ozAf66B5kp25g4lIo@z> 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