In message: <20100312171758.gb31...@dragon.nuxi.org> "David O'Brien" <obr...@freebsd.org> writes: : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: : > In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com> : > Garrett Cooper <yanef...@gmail.com> writes: : > : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel <swhet...@gmail.com> wrote: : > : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : > : > <mike.jaku...@intertainservices.com> 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<n> depends on : conf/NOTES:# COMPAT_FREEBSD<n+1>, COMPAT_FREEBSD<n+2>, 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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"