HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
Nathan Whitehorn
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
>>>>> 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
That sounds a bit confusing, compatibility with FreeBSD 3.2?
Sean C. Farley
> 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
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
Agreed. Is it possible to change the name again because it really
hasn't gotten much traction yet?
Thanks,
-Garrett
M. Warner Losh
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
Just for that, I nominate Nathan rename the option to
COMPAT_FLYING_MONKEYS32.
Scott Long
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
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
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
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
> 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
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
> 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
"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
"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
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
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
: > : 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
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
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
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
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
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)
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
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
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
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
Yes, I think this sounds like the best approach.
--
John Baldwin