Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32

In message: <20100312171758.GB31089_at_dragon.NUXI.org>
            "David O'Brien" <obrien_at_freebsd.org> writes:
: On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
: > In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5c4d_at_mail.gmail.com>
: >             Garrett Cooper <yanefbsd_at_gmail.com> writes:
: > : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel <swhetzel_at_gmail.com> wrote:
: > : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
: > : > <mike.jakubik_at_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