From owner-freebsd-arm@FreeBSD.ORG Thu Jun 28 22:15:18 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A8831065672 for ; Thu, 28 Jun 2012 22:15:18 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 79EA88FC14 for ; Thu, 28 Jun 2012 22:15:18 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Ty861j0060S2fkCA1yFJJ5; Thu, 28 Jun 2012 22:15:18 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta09.emeryville.ca.mail.comcast.net with comcast id TyFG1j01D4NgCEG8VyFH0G; Thu, 28 Jun 2012 22:15:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q5SMFFTr048830; Thu, 28 Jun 2012 16:15:15 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Tim Kientzle In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Jun 2012 16:15:15 -0600 Message-ID: <1340921715.1110.100.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Naming mess... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:15:18 -0000 On Tue, 2012-06-26 at 22:21 -0700, Tim Kientzle wrote: > I've been building on Warner's ARMv6 cleanup patches and > have them almost ready to commit to the armv6 tree (including > the necessary configuration glue for GCC to actually default > properly). > > In the process, I've uncovered the following confusing bit of naming: > > __ARM_ARCH_6__ > _ARM_ARCH_6 > ARM_ARCH_6 > > The above are three symbols defined in different parts > of the code with entirely different meanings. The > pattern extends in the obvious way. > > After some tracing, I figured out what they mean today: > > __ARM_ARCH_6__ is defined by GCC if it is currently targeting a processor that is exactly ARMv6. Two such symbols are never defined at the same time. The patches I'm working on arrange for this to be properly set in the armv6 builds.[0] > > _ARM_ARCH_6 is defined in asm.h (and has been redefined elsewhere, but I'm removing those) to indicate that the currently targeted processor is _at_least_ ARMv6. Several such macros can be defined at the same time. These are more useful in practice than the GCC symbols. Unfortunately, besides the poor naming, defining these symbols in asm.h means they cannot be used in C code. > > ARM_ARCH_6 is used within the kernel source to indicate that support routines should be included for this class of processor. Multiple such symbols can be defined at the same time if you're building a kernel with support for multiple CPUs. > > Here's what I would like to do: > > * The first is a given and we should leave it alone. The patches I'm cleaning up make this useful in the armv6 tree. > > * The second I would like to move out of asm.h so it can be used in C code. I would like to rename it to _HAVE_ARMv6_INSTRUCTIONS, which I think is clearer. I have renamed it in my patches but not yet moved it to another header. Suggestions appreciated. > > "NEED_ARM_ARCH_6_SUPPORT" * Someday, I would like to rename the third one, though I don't have a concrete proposal yet. ("NEED_ARM_ARCH_6_SUPPORT" is expressive but wordy; better suggestions appreciated.) > > Cheers, > > Tim > > [0] This page has a nice table: https://wiki.edubuntu.org/ARM/Thumb2PortingHowto > I'm not working with armv6 stuff yet, but I like all of what you propose. I can't help but note that NEED_ARM_ARCH_6_SUPPORT is actually shorter than _HAVE_ARMv6_INSTRUCTIONS. If it's just too wordy, maybe the "NEED_" part could be left off. -- Ian