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
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
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/
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
Mike Jakubik
> As a result of importing 32-bit compatibility support for non-x86
>
That sounds a bit confusing, compatibility with FreeBSD 3.2?
Scot Hetzel
<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?
>
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
> 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?
Thanks,
-Garrett
M. Warner Losh
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?
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
> 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.
>
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
> In message: <7d6fde3d1003111720g7d...@mail.gmail.com>
> Garrett Cooper <yane...@gmail.com> writes:
> : > 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?
>
> 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?
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
> 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."
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
> On Mar 11, 2010, at 6:14 PM, Scot Hetzel 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.
>
> I caught the humor in the first couple of replies, but you sound
> serious. Wow.
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.
Julian Elischer
> 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.
>
just add BIT on the end..
COMPAT_FREEBSD32BIT
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
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 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.
: > : 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
joe
one for the public network.
The private network is all on the same vlan. All 6 nics are on the same
switch. All connections are 1000tx Full Duplex.
I will call the servers Box A, Box B, and Box C.
When i FTP data between Box A & B i get abou 25MB/sec.
When i FTP data from Box C to Box A or B, i get about 20MB/sec.
When i FTP data from Box A to C i get 10MB/sec
When i FTP data from Box B to C i get 200KB/sec...
Can anyone suggest why i might only be getting 200KB when transfering
data from Box B to C but not when transferring data from Box A to C?
Thanks in advance!
Ian FREISLICH
> I have 3 boxes, each with two nics. One nic for the private network and
> one for the public network.
> The private network is all on the same vlan. All 6 nics are on the same
> switch. All connections are 1000tx Full Duplex.
>
> I will call the servers Box A, Box B, and Box C.
>
> When i FTP data between Box A & B i get abou 25MB/sec.
> When i FTP data from Box C to Box A or B, i get about 20MB/sec.
> When i FTP data from Box A to C i get 10MB/sec
> When i FTP data from Box B to C i get 200KB/sec...
>
> Can anyone suggest why i might only be getting 200KB when transfering
> data from Box B to C but not when transferring data from Box A to C?
Is the hardware exactly the same on all 3 hosts? From your enumeration
it looks like there's something special about box C.
How busy are the disks? One of the problems with FTP, at least the
last time I tried to use it for benchmarking was that it used tiny,
tiny transfers to and from disk. Strangely scp did better even
with the crypto overhead. Have you tried using netperf to test the
network performance?
Have you checked your cables? I've seen all sorts of wierd problems
caused by cables. netstat -ni should give an idea of transmission
problems. If the switch is a managed switch, you can also check
its interface counters.
Ian
--
Ian Freislich
joe
> joe wrote:
>
>> I have 3 boxes, each with two nics. One nic for the private network and
>> one for the public network.
>> The private network is all on the same vlan. All 6 nics are on the same
>> switch. All connections are 1000tx Full Duplex.
>>
>> I will call the servers Box A, Box B, and Box C.
>>
>> When i FTP data from Box C to Box A or B, i get about 20MB/sec.
>> When i FTP data from Box A to C i get 10MB/sec
>> When i FTP data from Box B to C i get 200KB/sec...
>>
>> Can anyone suggest why i might only be getting 200KB when transfering
>> data from Box B to C but not when transferring data from Box A to C?
>>
> Is the hardware exactly the same on all 3 hosts? From your enumeration
> it looks like there's something special about box C.
>
> How busy are the disks? One of the problems with FTP, at least the
> last time I tried to use it for benchmarking was that it used tiny,
> tiny transfers to and from disk. Strangely scp did better even
> with the crypto overhead. Have you tried using netperf to test the
> network performance?
>
> Have you checked your cables? I've seen all sorts of wierd problems
> caused by cables. netstat -ni should give an idea of transmission
> problems. If the switch is a managed switch, you can also check
> its interface counters.
>
> Ian
>
> --
> Ian Freislich
>
Thanks for the help!
The servers are mostly different. Server A & B run on consumer grade
motherboards/ram/nics. They both have a 12 disk raid 5 setup. Server C
is a dual quad core xeon processor supermicro server. It's Disk setup is
raid5 using the intel raid matrix. The switch is managed but i dont have
the login information for it (been years since i've had to log in ;().
The switch is a netgear gigabit switch. I've had the cables replaced as
well as trying two different ports on the switch, and ended up with the
same results. I've included the netstat -ni results below. While we
might be at a disadvantage until i get access to the managed switch, is
there anything else we might be able to try , to resolve the problem?
Joe
Name Mtu Network Address Ipkts Ierrs Idrop
Opkts Oerrs Coll
igb0 1500 <Link#1> 00:30:48:9f:11:04 8617 0 0
6108 0 0
igb0 1500 216.105.91.14 216.105.91.145 7066 - -
6082 - -
igb1 1500 <Link#2> 00:30:48:9f:11:05 3126 0 0
680 0 0
ipfw0 65536 <Link#3> 0 0 0
0 0 0
lo0 16384 <Link#4> 0 0 0
0 0 0
lo0 16384 fe80:4::1/64 fe80:4::1 0 - -
0 - -
lo0 16384 ::1/128 ::1 0 - -
0 - -
lo0 16384 127.0.0.0/8 127.0.0.1 0 - -
0 - -
pflog 33152 <Link#5> 0 0 0
0 0 0
vlan1 1500 <Link#6> 00:30:48:9f:11:05 1374 0 0
680 0 11
vlan1 1500 192.168.1.0/2 192.168.1.2 796 - -
677 - -
vlan1 1500 192.168.1.210 192.168.1.210 2 - -
0 - -
vlan1 1500 192.168.1.211 192.168.1.211 0 - -
0 - -
vlan1 1500 192.168.1.212 192.168.1.212 0 - -
0 - -
vlan1 1500 192.168.1.213 192.168.1.213 0 - -
0 - -
vlan1 1500 192.168.1.214 192.168.1.214 0 - -
0 - -
vlan1 1500 192.168.1.215 192.168.1.215 0 - -
0 - -
vlan1 1500 192.168.1.216 192.168.1.216 0 - -
0 - -
vlan1 1500 192.168.1.217 192.168.1.217 0 - -
0 - -
vlan1 1500 192.168.1.218 192.168.1.218 0 - -
0 - -
vlan1 1500 192.168.1.219 192.168.1.219 0 - -
0 - -