From owner-freebsd-current@FreeBSD.ORG Fri Mar 12 19:53:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B2A6106566B; Fri, 12 Mar 2010 19:53:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 099498FC0C; Fri, 12 Mar 2010 19:53:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2CJoPZN071426; Fri, 12 Mar 2010 12:50:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 12 Mar 2010 12:50:32 -0700 (MST) Message-Id: <20100312.125032.270969355930630649.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20100312171758.GB31089@dragon.NUXI.org> References: <7d6fde3d1003111720g7dccf93w1f51db88758a5c4d@mail.gmail.com> <20100311.192423.683591382013853731.imp@bsdimp.com> <20100312171758.GB31089@dragon.NUXI.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: yanefbsd@gmail.com, freebsd-current@freebsd.org, nwhitehorn@freebsd.org, swhetzel@gmail.com Subject: Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 19:53:25 -0000 In message: <20100312171758.GB31089@dragon.NUXI.org> "David O'Brien" writes: : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: : > In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5c4d@mail.gmail.com> : > Garrett Cooper writes: : > : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel wrote: : > : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : > : > wrote: : > : >> On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: : > : >>> As a result of importing 32-bit compatibility support for non-x86 : > : >>> 64-bit platforms, the kernel options COMPAT_IA32 has been renamed : > : >>> COMPAT_FREEBSD32 in revision 205014, so all kernel configurations : > : >>> including this option must be modified accordingly. : > : >> : > : >> That sounds a bit confusing, compatibility with FreeBSD 3.2? : > : >> : > : > I agree that the name COMPAT_FREEBSD32 is confusing, does it mean : > : > compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. : > : > : > : > A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. : > : : > : Agreed. Is it possible to change the name again because it really : > : hasn't gotten much traction yet? : > : > What does the name matter, really? : : Yes names matter. Otherwise we would have made it "DEF8931". #define : names are chosen to be self-documenting. I'd maintain that this name is self-documenting as well. Obviously you can take the what does the name matter to an extreme. However, for names that meet a minimum threshold of conformity, there reaches a point where arguing over them is counter productive. I believe that this name meets those minimum requirements. : $ grep COMPAT_FREEBSD conf/* : conf/NOTES:# Note that as a general rule, COMPAT_FREEBSD depends on : conf/NOTES:# COMPAT_FREEBSD, COMPAT_FREEBSD, etc. : conf/NOTES:options COMPAT_FREEBSD4 : conf/NOTES:options COMPAT_FREEBSD5 : conf/NOTES:options COMPAT_FREEBSD6 : conf/NOTES:options COMPAT_FREEBSD7 : conf/options:COMPAT_FREEBSD4 opt_compat.h : conf/options:COMPAT_FREEBSD5 opt_compat.h : conf/options:COMPAT_FREEBSD6 opt_compat.h : conf/options:COMPAT_FREEBSD7 opt_compat.h : : COMPAT_FREEBSD32 is not the same as any of the other well established : "COMPAT_FREEBSD" macros. So I do see where this could lead to confusion : to users. This is where we disagree. Any confusion can be solved by documentation. See for example these other compat options: COMPAT_LINUX brings in the files in sys/compat/linux COMPAT_SVR4 brings in the files in sys/compat/svr4 and COMPAT_LINUX32 compiles the 32-bit linux support on 64-bit hosts. So the issue isn't as cut and dried as you might think. There's multiple different conventions used here in addition to your simple example. Users of 64-bit systems that will be using COMPAT_FREEBSD32 are likely to find this a natural extension of the COMPAT_LINUX32 that they are likely already using. Warner