HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
M. Warner Losh
imp at bsdimp.com
Fri Mar 12 19:53:25 UTC 2010
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
More information about the freebsd-current
mailing list