Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2919409imm; Wed, 16 May 2018 23:42:24 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrQ7M9eFMV/rDA5QNBU74IdnsPAOtQjAqNK8Y/ynnQDgUfYZXBfiZISL0IldGAWz0iC2iy2 X-Received: by 2002:a17:902:9a8b:: with SMTP id w11-v6mr4033374plp.75.1526539344882; Wed, 16 May 2018 23:42:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526539344; cv=none; d=google.com; s=arc-20160816; b=bx8nfxc/3QlVWcYikoAOSI8HWjOjUxuKNfXJ/l1WvtZ3vglcWdSqjXTtzUaXnhqsQf cNzw5ms6qWQBO5sLika5kWNHNNFNkqiOvZwCg7gk0c6ImFd2qXHKU7HjY/ZrOAhmPPEV EOb1i/UWh+qJT4HOpOv+i1uVMdfyPwqyc8NV11I/kKUo/4prKZ3di969zGM6LY8j8CWu GERvaT4yutmawwzV0O71tZw0GVh5p3hvq2yVqwOWoozX0ElZO63joS6tfZ17M2kc+vgt sLW7l+yiAEa4899Re5RmKBitqIKW+8hSC/WDn6xjqi/rL/FAv48Sl/jkA9hcuW/4DoOY t/pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=DkAbuY7CchLo98yU84/dZ/nvi2smmEKm7ejsVJ8vW48=; b=bSPYtogfhFxOzEMa6g7UvW952pFPO/pSR+ELnsi354XbykhlOrYRYlJooyUM3gPvVK +WLvRP/Ab1x8hZc4rlriECs5a3i0mSRsROW+emHYbV5VLrj/4razihf02uubTu2ysd1v lvmtk6l1fAPm/1ZCZmybwcZ6qqX5ek0n0uIV8SMXroYLJnWfsTgEBi5ceRs+J/2Z3YoK Agd84Z/kOheRBnk9ozU4+hfC7bbXlsR9O+G3y1wPsb7QAyyBLDDk48kv1YeXXiJPBETF Dmuxgr+NthusAybOx+arW4EuGqNrwnoxEAwlpFFJ1FCnbasBiaFKsOIofHGdZEoj05j+ WmUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h12-v6si4550565pfd.253.2018.05.16.23.42.10; Wed, 16 May 2018 23:42:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752160AbeEQGkd (ORCPT + 99 others); Thu, 17 May 2018 02:40:33 -0400 Received: from ozlabs.org ([203.11.71.1]:47325 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbeEQGkb (ORCPT ); Thu, 17 May 2018 02:40:31 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 40mhWV5C5Mz9s0y; Thu, 17 May 2018 16:40:22 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Dave Martin , linux-kernel@vger.kernel.org Cc: 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 , Palmer Dabbelt , Albert Ou , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Chris Zankel , Max Filippov Subject: Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations In-Reply-To: <1526480447-18185-1-git-send-email-Dave.Martin@arm.com> References: <1526480447-18185-1-git-send-email-Dave.Martin@arm.com> Date: Thu, 17 May 2018 16:40:19 +1000 Message-ID: <8736yqokdo.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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