HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32

8 views
Skip to first unread message

Nathan Whitehorn

unread,
Mar 11, 2010, 9:50:05 AM3/11/10
to FreeBSD-CURRENT Mailing List, freebs...@freebsd.org, freebs...@freebsd.org
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.
-Nathan

Hajimu UMEMOTO

unread,
Mar 11, 2010, 10:04:41 AM3/11/10
to Nathan Whitehorn, FreeBSD-CURRENT Mailing List, freebs...@freebsd.org, freebs...@freebsd.org
Hi,

>>>>> On Thu, 11 Mar 2010 08:50:05 -0600
>>>>> Nathan Whitehorn <nwhit...@freebsd.org> said:

nwhitehorn> As a result of importing 32-bit compatibility support for non-x86 64-bit
nwhitehorn> platforms, the kernel options COMPAT_IA32 has been renamed
nwhitehorn> COMPAT_FREEBSD32 in revision 205014, so all kernel configurations
nwhitehorn> including this option must be modified accordingly.

Doesn't this mean we cannot have FreeBSD version 32? :)

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

Mike Jakubik

unread,
Mar 11, 2010, 11:36:16 AM3/11/10
to freebsd...@freebsd.org

That sounds a bit confusing, compatibility with FreeBSD 3.2?

Sean C. Farley

unread,
Mar 11, 2010, 10:13:02 AM3/11/10
to Hajimu UMEMOTO, FreeBSD-CURRENT Mailing List, Nathan Whitehorn, freebs...@freebsd.org, freebs...@freebsd.org
On Fri, 12 Mar 2010, Hajimu UMEMOTO wrote:

> Hi,
>
>>>>>> On Thu, 11 Mar 2010 08:50:05 -0600
>>>>>> Nathan Whitehorn <nwhit...@freebsd.org> said:
>
> nwhitehorn> As a result of importing 32-bit compatibility support for non-x86 64-bit
> nwhitehorn> platforms, the kernel options COMPAT_IA32 has been renamed
> nwhitehorn> COMPAT_FREEBSD32 in revision 205014, so all kernel configurations
> nwhitehorn> including this option must be modified accordingly.
>
> Doesn't this mean we cannot have FreeBSD version 32? :)

Think like the U.S. government and push the problem off to the
great*N-grandchildren. ;)

Sean
--
s...@FreeBSD.org

Scot Hetzel

unread,
Mar 11, 2010, 8:14:29 PM3/11/10
to Nathan Whitehorn, freebsd...@freebsd.org
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.

Scot

Garrett Cooper

unread,
Mar 11, 2010, 8:20:08 PM3/11/10
to Scot Hetzel, freebsd...@freebsd.org, Nathan Whitehorn

Agreed. Is it possible to change the name again because it really
hasn't gotten much traction yet?
Thanks,
-Garrett

M. Warner Losh

unread,
Mar 11, 2010, 9:24:23 PM3/11/10
to yane...@gmail.com, freebsd...@freebsd.org, swhe...@gmail.com, nwhit...@freebsd.org
In message: <7d6fde3d1003111720g7d...@mail.gmail.com>
Garrett Cooper <yane...@gmail.com> writes:

What does the name matter, really?

This will be documented, and mirrors the kernel source
compat/freebsd32.

Put another way: if everybody that's going to comment on the name
would instead fix one bug from the PR database with the time they
spend commenting on it, would FreeBSD be better or worse off than
spending dozens of hours arguing over COMPAT_X32 vs COMPAT_Y32 vs
COMPAT_FLYING_MONKEYS?

Warner

Justin Hibbits

unread,
Mar 11, 2010, 9:44:24 PM3/11/10
to FreeBSD Current

Just for that, I nominate Nathan rename the option to
COMPAT_FLYING_MONKEYS32.

Scott Long

unread,
Mar 11, 2010, 10:54:32 PM3/11/10
to Scot Hetzel, freebsd...@freebsd.org, Nathan Whitehorn

Seriously, this is being debated? FreeBSD 3.2? Is this a joke? I caught the humor in the first couple of replies, but you sound serious. Wow.

Scott

Garrett Cooper

unread,
Mar 11, 2010, 11:24:57 PM3/11/10
to M. Warner Losh, swhe...@gmail.com, nwhit...@freebsd.org, freebsd...@freebsd.org

I can haz PR review then? Here's an easy one :)...

http://www.freebsd.org/cgi/query-pr.cgi?pr=144644

Thanks,
-Garrett

Gary Jennejohn

unread,
Mar 12, 2010, 5:36:25 AM3/12/10
to Garrett Cooper, freebsd...@freebsd.org
On Thu, 11 Mar 2010 20:24:57 -0800
Garrett Cooper <yane...@gmail.com> wrote:

> I can haz PR review then? Here's an easy one :)...
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=144644
>

Looks OK to me except I don't like the
if (something) {
one-line-of-code();
}
constructs, but according to style(9) these are sort-of OK, viz

Closing and opening braces go on the same line as the else. Braces that
are not necessary may be left out.
^^^^^^^^^^^^^^^
if (test)
stmt;
else if (bar) {
stmt;
stmt;
} else
stmt;

Saved by the "may."

---
Gary Jennejohn (gj@)

Ulrich Spörlein

unread,
Mar 12, 2010, 6:02:21 AM3/12/10
to Gary Jennejohn, Garrett Cooper, freebsd...@freebsd.org

True, but some folks (me included) really hate it, when different
bracing is used *within* the same statement. The example above really is
horrible. If one if/else-if clause needs braces, just brace them all. This
loses no vertical space (the dangling else excluded) and some folks find
it visually more pleasing/easier to read.

... hence begins the bikeshedding.

Bye,
Uli

David O'Brien

unread,
Mar 12, 2010, 12:17:58 PM3/12/10
to M. Warner Losh, yane...@gmail.com, freebsd...@freebsd.org, nwhit...@freebsd.org, swhe...@gmail.com
On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
> In message: <7d6fde3d1003111720g7d...@mail.gmail.com>
> Garrett Cooper <yane...@gmail.com> writes:
> : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel <swhe...@gmail.com> wrote:
> : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
> : > <mike.j...@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.

$ 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.

--
-- David (obr...@FreeBSD.org)

David O'Brien

unread,
Mar 12, 2010, 12:22:55 PM3/12/10
to Scott Long, Scot Hetzel, Nathan Whitehorn, freebsd...@freebsd.org

Yes it is. Where was it discussed first? I do not see anything in my
freebsd-arch or freebsd-current archive; or any other FreeBSD list.

If there wasn't already a well established meaning to "COMPAT_FREEBSD"
(grep for it in /usr/src/sys/conf/), there probably wouldn't be any real
complaints.

--
-- David (obr...@FreeBSD.org)

Mark Linimon

unread,
Mar 12, 2010, 1:59:49 PM3/12/10
to obr...@freebsd.org, Scott Long, Scot Hetzel, freebsd...@freebsd.org, Nathan Whitehorn
On Fri, Mar 12, 2010 at 09:22:55AM -0800, David O'Brien wrote:
> Yes it is. Where was it discussed first? I do not see anything in my
> freebsd-arch or freebsd-current archive; or any other FreeBSD list.

http://docs.freebsd.org/cgi/mid.cgi?4B971CA3.9090301

crossposted on amd64@, ia64@, emulation@.

mcl

Julian Elischer

unread,
Mar 12, 2010, 2:10:52 PM3/12/10
to Gary Jennejohn, Garrett Cooper, freebsd...@freebsd.org

"Green"

My personal preference is that if one clause requires braces,
they all get them so you would never see

"else {"

or

"} else"

just
"else"
or
"} else {"

I just find it helps keep everything correctly associated when reading.

>
> Bye,
> Uli
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

M. Warner Losh

unread,
Mar 12, 2010, 2:50:32 PM3/12/10
to obr...@freebsd.org, yane...@gmail.com, freebsd...@freebsd.org, nwhit...@freebsd.org, swhe...@gmail.com
In message: <20100312171...@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: <7d6fde3d1003111720g7d...@mail.gmail.com>
: > Garrett Cooper <yane...@gmail.com> writes:
: > : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel <swhe...@gmail.com> wrote:
: > : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
: > : > <mike.j...@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

Garance A Drosehn

unread,
Mar 15, 2010, 2:02:22 PM3/15/10
to Mark Linimon, obr...@freebsd.org, freebsd...@freebsd.org


While those are logical mailing lists for this topic to have come
up on, it shouldn't be much of a surprise that there are many
freebsd users and committers who are not on those lists. Many
people who do know about the existing COMPAT_FREEBSD* variables,
and thus will be surprised at this variable name.

My understanding is that there has already been a lot of furor
over this name, so let me first say I don't mean to infuriate
anyone. However, my own vote would be for some other name than
COMPAT_FREEBSD32.

--
Garance Alistair Drosehn = dro...@rpi.edu
Senior Systems Programmer or g...@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA

jhell

unread,
Mar 17, 2010, 8:06:56 AM3/17/10
to Garance A Drosehn, Mark Linimon, FreeBSD Current

On Mon, 15 Mar 2010 14:02, Garance A Drosehn wrote:
In Message: <p06240804c7c4248d6354@[128.113.24.47]>

> At 12:59 PM -0600 3/12/10, Mark Linimon wrote:
>> On Fri, Mar 12, 2010 at 09:22:55AM -0800, David O'Brien wrote:
>> > Yes it is. Where was it discussed first? I do not see anything
>> > in my freebsd-arch or freebsd-current archive; or any other
>> > FreeBSD list.
>>
>> http://docs.freebsd.org/cgi/mid.cgi?4B971CA3.9090301
>>
>> crossposted on amd64@, ia64@, emulation@.
>
>
> While those are logical mailing lists for this topic to have come
> up on, it shouldn't be much of a surprise that there are many
> freebsd users and committers who are not on those lists. Many
> people who do know about the existing COMPAT_FREEBSD* variables,
> and thus will be surprised at this variable name.
>
> My understanding is that there has already been a lot of furor
> over this name, so let me first say I don't mean to infuriate
> anyone. However, my own vote would be for some other name than
> COMPAT_FREEBSD32.
>
>

Perhaps COMPAT_ELF32 would be more well suited for this ?

$0.002

--

jhell

M. Warner Losh

unread,
Mar 22, 2010, 3:01:18 PM3/22/10
to obr...@freebsd.org, yane...@gmail.com, freebsd...@freebsd.org, nwhit...@freebsd.org, swhe...@gmail.com
In message: <20100322185...@dragon.NUXI.org>

"David O'Brien" <obr...@freebsd.org> writes:
: On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote:
: > : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote:
: > 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.
:
: I guess we'd have to take a poll to find out. Seems pretty cut and dried
: to me. COMPAT_FREEBSDn has an established context that does not match
: this new usage. That is - same bit'ness, compatibility with an older
: FreeBSD API for the same architecture. All the other COMPAT_* are for
: foreign ABI compatibility. COMPAT_LINUX32 possibly should have been
: "COMPAT_LINUX_X86_64". (or is it MI and is usable as-is for PowerPC
: and MIPS? I haven't looked that deeply at the code.)

no, COMPAT_LINUX32 is the right name. While we don't have PowerPC or
MIPS linux emulation bits in the kernel, the code if for dealing with
running 32-bit binaries on 64-bit machines. There may be a little
leakage of x86 specific goo here, but not a lot.

Warner

David O'Brien

unread,
Mar 22, 2010, 2:53:31 PM3/22/10
to M. Warner Losh, yane...@gmail.com, freebsd...@freebsd.org, nwhit...@freebsd.org, swhe...@gmail.com

I guess we'd have to take a poll to find out. Seems pretty cut and dried


to me. COMPAT_FREEBSDn has an established context that does not match
this new usage. That is - same bit'ness, compatibility with an older
FreeBSD API for the same architecture. All the other COMPAT_* are for
foreign ABI compatibility. COMPAT_LINUX32 possibly should have been
"COMPAT_LINUX_X86_64". (or is it MI and is usable as-is for PowerPC
and MIPS? I haven't looked that deeply at the code.)

> 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.

You know I am such a user - and I don't think it is so clear given the
existence (and purpose) of "COMPAT_FREEBSDn" for the past many years.

While it does match the directory name of 'sys/compat/freebsd32', it may
be that "freebsd32" was a poor choice for that directory's name. But
given the recent discussion in another thread - I won't even suggest
we rename it.

--
-- David (obr...@FreeBSD.org)

M. Warner Losh

unread,
Mar 22, 2010, 3:09:39 PM3/22/10
to obr...@freebsd.org, yane...@gmail.com, freebsd...@freebsd.org, nwhit...@freebsd.org, swhe...@gmail.com
P.S. I think that there's much traction to the idea of moving from
COMPAT_FREEBSDx to some other variable called, for example,
COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries
as old as FreeBSD x.0, and have all the other magic handled behind the
scenes. This would render the inconsistency with COMPAT_FREEBSDx part
of the debate completely moot.

Warner

Daniel Eischen

unread,
Mar 22, 2010, 3:42:22 PM3/22/10
to M. Warner Losh, freebsd...@freebsd.org
[ Some CC's stripped ]

Doesn't matter. We're still use to COMPAT_FREEBSDx since
it's been here so long. So regardless if you rename them
to COMPAT_FREEBSD_BACK_TO=x, it is still potentially confusing.

COMPAT_ARCH32 and all other choices David mentions seem like
much better names - even if there wasn't any existing
COMPAT_FREEBSDx knobs.

My $0.02.

--
DE

jhell

unread,
Mar 23, 2010, 7:39:52 PM3/23/10
to Daniel Eischen, freebsd...@freebsd.org, M. Warner Losh


Ill say it again if I have to... COMPAT_ELF32 or possibly even
ELF32_SUPPORT seems to me as a very likely possibility.

Maybe even:
SUPPORT_ELF32= # Support for 32 Bit ELF Binaries

This would add its own name structure that is expandabe later-in-future
when 128 Bit systems come out ;)

Regards,

--

jhell

Carlos A. M. dos Santos

unread,
Mar 23, 2010, 8:49:49 PM3/23/10
to jhell, Daniel Eischen, freebsd...@freebsd.org, M. Warner Losh

ELF may go away sometime, just like a.out went to the holly pastures.

--
Not so young, but still crying out
Full of anger full of doubt

Svein Skogen (Listmail Account)

unread,
Mar 23, 2010, 8:54:54 PM3/23/10
to freebsd...@freebsd.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It may. But having a confusing directive (the COMPAT_FREEBSD32 vs
COMPAT_FREEBSD[4567]) is likely to stay with us for a long, long, long
time. Just like the scarring after a bullet wound to the foot.

//Svein

- --
- --------+-------------------+-------------------------------
/"\ |Svein Skogen | sv...@d80.iso100.no
\ / |Solberg �stli 9 | PGP Key: 0xE5E76831
X |2020 Skedsmokorset | sv...@jernhuset.no
/ \ |Norway | PGP Key: 0xCE96CE13
| | sv...@stillbilde.net
ascii | | PGP Key: 0x58CD33B6
ribbon |System Admin | svein-l...@stillbilde.net
Campaign|stillbilde.net | PGP Key: 0x22D494A4
+-------------------+-------------------------------
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle: SS16503-RIPE
- --------+-------------------+-------------------------------
If you really are in a hurry, mail me at
svein-...@stillbilde.net
This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- ------------------------------------------------------------
Picture Gallery:
https://gallery.stillbilde.net/v/svein/
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkupYt4ACgkQODUnwSLUlKTWHQCePMfrdHKqTryA5DQ4T8aRlKfM
jwUAnRmjdXdAwXB2gEvgNV8609ctqDY9
=q+B1
-----END PGP SIGNATURE-----

jhell

unread,
Mar 23, 2010, 9:08:59 PM3/23/10
to Carlos A. M. dos Santos, Daniel Eischen, freebsd...@freebsd.org, M. Warner Losh

On Tue, 23 Mar 2010 20:49, Carlos A. M. dos Santos wrote:
In Message-Id: <e71790db1003231749n5ed...@mail.gmail.com>

Alright, that's like anything else in the world of computer sciences. But
that still does not dismiss its purpose and right now ELF is in full swing
and when the time comes... 10, 20, 30 years down the road then you simply
add something else but by that point 32 bit computing will probably be
history so there wont need to be any of this fuss for ELF or 32 bit
support at that time.


--

jhell

pluknet

unread,
Apr 5, 2010, 11:12:08 AM4/5/10
to freebsd...@freebsd.org
Hi,

the interesting part for me is how to properly assert now a value of e.g.
KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches
(say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/).

--
wbr,
pluknet

Nathan Whitehorn

unread,
Apr 6, 2010, 11:24:21 AM4/6/10
to pluknet, freebsd...@freebsd.org
Probably the cleanest thing would be to set KINFO_PROC_SIZE in
machine/proc.h instead of where it is now, and then also define a
KINFO_PROC32_SIZE or something in the same place. Also, that would be a
really nice feature.
-Nathan

John Baldwin

unread,
Apr 7, 2010, 3:49:41 PM4/7/10
to freebsd...@freebsd.org, pluknet, Nathan Whitehorn

Yes, I think this sounds like the best approach.

--
John Baldwin

Reply all
Reply to author
Forward
0 new messages