From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 11:33:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D48CD1065670 for ; Mon, 18 Apr 2011 11:33:34 +0000 (UTC) (envelope-from abuse@cj-vollblutaraber.de) Received: from res7.worldserver.net (res7.worldserver.net [217.13.199.17]) by mx1.freebsd.org (Postfix) with SMTP id 243D08FC28 for ; Mon, 18 Apr 2011 11:33:33 +0000 (UTC) Received: (qmail 3875 invoked by uid 65534); 18 Apr 2011 11:22:09 -0000 Date: 18 Apr 2011 11:22:09 -0000 Message-ID: <20110418112209.3874.qmail@res7.worldserver.net> To: freebsd-arch@freebsd.org From: Dr.Ban Ki-moon. MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: Congratulation, URGENT RESPONSE IS NEEDED X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: courierservice@one.co.il List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:33:34 -0000 Congratulation, I just received a call from the Director of Scarlet Courier Service Company Nigeria that the consignment box that was sent to you was returned due to wrong address, This consignment box contained your $5.500.000.00 united state dollars, Your compensation fund.Therefore call the director (Williams Wright) on Tel: (+234705-550-1921 ) email him at: (couierservice@one.co.il) and give him your correct address and Phone number: So the Information you are Required to Reconfirm to the Agent is as Follow. (1)Your Full Name============= (2)Mobile Phone Number====== (3)Current Home Address======== (4)Occupation================= (5)Fax Number================ (6)Country==================== (7)City===================== (8)Nearest Airport ============== (9)A Copy of Your I D For Identification Use this code (XA-8550) as the subject of your mail to them for identification. Yours Truly. Dr. Ban Ki-moon. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 13:42:56 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF091065672; Mon, 18 Apr 2011 13:42:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5073D8FC1B; Mon, 18 Apr 2011 13:42:56 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:adc5:19f9:a31a:3bcd] (unknown [IPv6:2001:7b8:3a7:0:adc5:19f9:a31a:3bcd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 495B85C59; Mon, 18 Apr 2011 15:42:55 +0200 (CEST) Message-ID: <4DAC3FD9.1060603@FreeBSD.org> Date: Mon, 18 Apr 2011 15:42:49 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: "arch@freebsd.org" , "current@freebsd.org" Content-Type: multipart/mixed; boundary="------------000008000402090004000307" Cc: Subject: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:42:57 -0000 This is a multi-part message in MIME format. --------------000008000402090004000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reviving an old thread(*), I would like to propose to finally remove the Intel C Compiler support from share/mk and other places. As mentioned in that thread, the ICC bits simply do not work anymore, and no one has volunteered to fix it for many years. Please review the attached patch, which cleans up the ICC bits. *) http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019179.html --------------000008000402090004000307 Content-Type: text/plain; name="remove-icc-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="remove-icc-1.diff" diff --git a/share/mk/bsd.cpu.mk b/share/mk/bsd.cpu.mk index 99c28aa..0670bff 100644 --- a/share/mk/bsd.cpu.mk +++ b/share/mk/bsd.cpu.mk @@ -91,31 +91,6 @@ _CPUCFLAGS = -march=prescott . else _CPUCFLAGS = -march=${CPUTYPE} . endif # GCC on 'i386' -. if ${CPUTYPE} == "crusoe" -_ICC_CPUCFLAGS = -tpp6 -xiM -. elif ${CPUTYPE} == "athlon-mp" || ${CPUTYPE} == "athlon-xp" || \ - ${CPUTYPE} == "athlon-4" -_ICC_CPUCFLAGS = -tpp6 -xiMK -. elif ${CPUTYPE} == "athlon-tbird" || ${CPUTYPE} == "athlon" -_ICC_CPUCFLAGS = -tpp6 -xiM -. elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2" || ${CPUTYPE} == "k6" -_ICC_CPUCFLAGS = -tpp6 -xi -. elif ${CPUTYPE} == "k5" -_ICC_CPUCFLAGS = -tpp5 -. elif ${CPUTYPE} == "pentium4" || ${CPUTYPE} == "pentium4m" -_ICC_CPUCFLAGS = -tpp7 -xiMKW -. elif ${CPUTYPE} == "pentium3" || ${CPUTYPE} == "pentium3m" || \ - ${CPUTYPE} == "pentium-m" -_ICC_CPUCFLAGS = -tpp6 -xiMK -. elif ${CPUTYPE} == "pentium2" || ${CPUTYPE} == "pentiumpro" -_ICC_CPUCFLAGS = -tpp6 -xiM -. elif ${CPUTYPE} == "pentium-mmx" -_ICC_CPUCFLAGS = -tpp5 -xM -. elif ${CPUTYPE} == "pentium" -_ICC_CPUCFLAGS = -tpp5 -. else -_ICC_CPUCFLAGS = -. endif # ICC on 'i386' . elif ${MACHINE_CPUARCH} == "amd64" _CPUCFLAGS = -march=${CPUTYPE} . elif ${MACHINE_CPUARCH} == "arm" @@ -242,9 +217,5 @@ CFLAGS += -G0 # NB: COPTFLAGS is handled in /usr/src/sys/conf/kern.pre.mk .if !defined(NO_CPU_CFLAGS) -. if ${CC} == "icc" -CFLAGS += ${_ICC_CPUCFLAGS} -. else CFLAGS += ${_CPUCFLAGS} -. endif .endif diff --git a/share/mk/bsd.dep.mk b/share/mk/bsd.dep.mk index 459a9c3..c452528 100644 --- a/share/mk/bsd.dep.mk +++ b/share/mk/bsd.dep.mk @@ -125,13 +125,8 @@ depend: beforedepend ${DEPENDFILE} afterdepend # Different types of sources are compiled with slightly different flags. # Split up the sources, and filter out headers and non-applicable flags. -.if ${CC:T:Micc} == "icc" -MKDEP_CFLAGS= ${CFLAGS:M-X*} ${CFLAGS:M-[BIDU]*} -MKDEP_CXXFLAGS= ${CXXFLAGS:M-X*} ${CXXFLAGS:M-[BIDU]*} -.else MKDEP_CFLAGS= ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BIDU]*} MKDEP_CXXFLAGS= ${CXXFLAGS:M-nostdinc*} ${CXXFLAGS:M-[BIDU]*} -.endif DPSRCS+= ${SRCS} ${DEPENDFILE}: ${DPSRCS} diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk index 9d655b6..943010c 100644 --- a/share/mk/bsd.lib.mk +++ b/share/mk/bsd.lib.mk @@ -65,11 +65,7 @@ PICFLAG=-fpic .endif .endif -.if ${CC:T:Micc} == "icc" -PO_FLAG=-p -.else PO_FLAG=-pg -.endif .c.po: ${CC} ${PO_FLAG} ${PO_CFLAGS} -c ${.IMPSRC} -o ${.TARGET} diff --git a/share/mk/bsd.sys.mk b/share/mk/bsd.sys.mk index fc5ec40..796d169 100644 --- a/share/mk/bsd.sys.mk +++ b/share/mk/bsd.sys.mk @@ -11,20 +11,18 @@ # the default is gnu99 for now CSTD ?= gnu99 -.if ${CC:T:Micc} != "icc" -. if ${CSTD} == "k&r" +.if ${CSTD} == "k&r" CFLAGS += -traditional -. elif ${CSTD} == "c89" || ${CSTD} == "c90" +.elif ${CSTD} == "c89" || ${CSTD} == "c90" CFLAGS += -std=iso9899:1990 -. elif ${CSTD} == "c94" || ${CSTD} == "c95" +.elif ${CSTD} == "c94" || ${CSTD} == "c95" CFLAGS += -std=iso9899:199409 -. elif ${CSTD} == "c99" +.elif ${CSTD} == "c99" CFLAGS += -std=iso9899:1999 -. else +.else CFLAGS += -std=${CSTD} -. endif .endif -.if !defined(NO_WARNS) && ${CC:T:Micc} != "icc" +.if !defined(NO_WARNS) # -pedantic is problematic because it also imposes namespace restrictions #CFLAGS += -pedantic . if defined(WARNS) @@ -82,9 +80,8 @@ CWARNFLAGS += -Wno-format CWARNFLAGS += -Wno-unknown-pragmas .endif -.if ${MK_SSP} != "no" && ${CC:T:Micc} != "icc" && \ - ${MACHINE_CPUARCH} != "ia64" && \ - ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" +.if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \ + ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" # Don't use -Wstack-protector as it breaks world with -Werror. SSP_CFLAGS ?= -fstack-protector CFLAGS += ${SSP_CFLAGS} diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk index 01b1438..1e58378 100644 --- a/sys/conf/kern.mk +++ b/sys/conf/kern.mk @@ -6,14 +6,9 @@ # Note that the newly added -Wcast-qual is responsible for generating # most of the remaining warnings. Warnings introduced with -Wall will # also pop up, but are easier to fix. -.if ${CC:T:Micc} == "icc" -#CWARNFLAGS= -w2 # use this if you are terribly bored -CWARNFLAGS= -.else CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -Wundef -Wno-pointer-sign -fformat-extensions -.endif # # The following flags are next up for working on: # -W @@ -29,7 +24,7 @@ CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ # operations inside the kernel itself. These operations are exclusively # reserved for user applications. # -.if ${MACHINE_CPUARCH} == "i386" && ${CC:T:Micc} != "icc" +.if ${MACHINE_CPUARCH} == "i386" .if ${CC:T:Mclang} != "clang" CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 .endif @@ -100,22 +95,13 @@ INLINE_LIMIT?= 8000 # GCC 3.0 and above like to do certain optimizations based on the # assumption that the program is linked against libc. Stop this. # -.if ${CC:T:Micc} == "icc" -CFLAGS+= -nolib_inline -.else CFLAGS+= -ffreestanding -.endif - -.if ${CC:T:Micc} == "icc" -CFLAGS+= -restrict -.endif # # GCC SSP support. # -.if ${MK_SSP} != "no" && ${CC:T:Micc} != "icc" && \ - ${MACHINE_CPUARCH} != "ia64" && ${MACHINE_CPUARCH} != "arm" && \ - ${MACHINE_CPUARCH} != "mips" +.if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \ + ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" CFLAGS+= -fstack-protector .endif diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk index 4deaea8..db244c4 100644 --- a/sys/conf/kern.pre.mk +++ b/sys/conf/kern.pre.mk @@ -23,38 +23,25 @@ NM?= nm OBJCOPY?= objcopy SIZE?= size -.if ${CC:T:Micc} == "icc" -COPTFLAGS?= -O -.else -. if defined(DEBUG) +.if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g -. else +.else _MINUS_O= -O2 -. endif -. if ${MACHINE_CPUARCH} == "amd64" +.endif +.if ${MACHINE_CPUARCH} == "amd64" COPTFLAGS?=-O2 -frename-registers -pipe -. else +.else COPTFLAGS?=${_MINUS_O} -pipe -. endif -. if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) +.endif +.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) COPTFLAGS+= -fno-strict-aliasing -. endif .endif .if !defined(NO_CPU_COPTFLAGS) -. if ${CC:T:Micc} == "icc" -COPTFLAGS+= ${_ICC_CPUCFLAGS:C/(-x[^M^K^W]+)[MKW]+|-x[MKW]+/\1/} -. else COPTFLAGS+= ${_CPUCFLAGS} -. endif .endif -.if ${CC:T:Micc} == "icc" -C_DIALECT= -NOSTDINC= -X -.else C_DIALECT= -std=c99 NOSTDINC= -nostdinc -.endif INCLUDES= ${NOSTDINC} ${INCLMAGIC} -I. -I$S @@ -89,36 +76,31 @@ INCLUDES+= -I$S/dev/cxgb -I$S/dev/cxgbe CFLAGS= ${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS} CFLAGS+= ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -.if ${CC:T:Micc} != "icc" .if ${CC:T:Mclang} != "clang" CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT} -.if ${MACHINE_CPUARCH} != "mips" +. if ${MACHINE_CPUARCH} != "mips" CFLAGS+= --param inline-unit-growth=100 CFLAGS+= --param large-function-growth=1000 -.else +. else # XXX Actually a gross hack just for Octeon because of the Simple Executive. CFLAGS+= --param inline-unit-growth=10000 CFLAGS+= --param large-function-growth=100000 CFLAGS+= --param max-inline-insns-single=10000 -.endif +. endif .endif WERROR?= -Werror -.endif # XXX LOCORE means "don't declare C stuff" not "for locore.s". ASM_CFLAGS= -x assembler-with-cpp -DLOCORE ${CFLAGS} .if defined(PROFLEVEL) && ${PROFLEVEL} >= 1 -.if ${CC:T:Micc} == "icc" -.error "Profiling doesn't work with icc" -.endif CFLAGS+= -DGPROF -falign-functions=16 -.if ${PROFLEVEL} >= 2 +. if ${PROFLEVEL} >= 2 CFLAGS+= -DGPROF4 -DGUPROF PROF= -pg -mprofiler-epilogue -.else +. else PROF= -pg -.endif +. endif .endif DEFINED_PROF= ${PROF} diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk index 2239d66..6d22e41 100644 --- a/sys/conf/kmod.mk +++ b/sys/conf/kmod.mk @@ -88,25 +88,17 @@ __KLD_SHARED=yes __KLD_SHARED=no .endif -.if ${CC:T:Micc} == "icc" -CFLAGS:= ${CFLAGS:C/(-x[^M^K^W]+)[MKW]+|-x[MKW]+/\1/} -.else -. if !empty(CFLAGS:M-O[23s]) && empty(CFLAGS:M-fno-strict-aliasing) +.if !empty(CFLAGS:M-O[23s]) && empty(CFLAGS:M-fno-strict-aliasing) CFLAGS+= -fno-strict-aliasing -. endif +.endif WERROR?= -Werror -.endif CFLAGS+= ${WERROR} CFLAGS+= -D_KERNEL CFLAGS+= -DKLD_MODULE # Don't use any standard or source-relative include directories. -.if ${CC:T:Micc} == "icc" -NOSTDINC= -X -.else CSTD= c99 NOSTDINC= -nostdinc -.endif CFLAGS:= ${CFLAGS:N-I*} ${NOSTDINC} ${INCLMAGIC} ${CFLAGS:M-I*} .if defined(KERNBUILDDIR) CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h @@ -121,7 +113,7 @@ CFLAGS+= -I. -I@ # for example. CFLAGS+= -I@/contrib/altq -.if ${CC:T:Micc} != "icc" && ${CC:T:Mclang} != "clang" +.if ${CC:T:Mclang} != "clang" CFLAGS+= -finline-limit=${INLINE_LIMIT} CFLAGS+= --param inline-unit-growth=100 CFLAGS+= --param large-function-growth=1000 @@ -129,9 +121,7 @@ CFLAGS+= --param large-function-growth=1000 # Disallow common variables, and if we end up with commons from # somewhere unexpected, allocate storage for them in the module itself. -.if ${CC:T:Micc} != "icc" CFLAGS+= -fno-common -.endif LDFLAGS+= -d -warn-common CFLAGS+= ${DEBUG_FLAGS} diff --git a/sys/dev/aic7xxx/aicasm/Makefile b/sys/dev/aic7xxx/aicasm/Makefile index c077285..b8352d6 100644 --- a/sys/dev/aic7xxx/aicasm/Makefile +++ b/sys/dev/aic7xxx/aicasm/Makefile @@ -24,12 +24,7 @@ WARNS?= 5 DEPENDFILE= .depend_aicasm .endif -.if ${CC:T:Micc} == "icc" -CFLAGS+= -restrict -NOSTDINC= -X -.else NOSTDINC= -nostdinc -.endif CFLAGS+= ${NOSTDINC} -I/usr/include -I. .ifdef MAKESRCPATH CFLAGS+= -I${MAKESRCPATH} --------------000008000402090004000307-- From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 15:03:45 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8A5106566C; Mon, 18 Apr 2011 15:03:45 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BAB888FC1A; Mon, 18 Apr 2011 15:03:44 +0000 (UTC) Received: by qwc9 with SMTP id 9so2952248qwc.13 for ; Mon, 18 Apr 2011 08:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=X4cK8GB8L67Anjw2P2pVJOvBlQxXMlQy07tdCM7oW7c=; b=InZXQ/h87661mmtfP8rXDXK0TtXv++HAy2J/TpmJ0kPqamm9vDKM5fHakUCVMOddud ZygUJRVIVZ6kqVef5lzqQ4gVl5crgqpMiEkC5snicOd2BgTyPkJFYepj62UQyqVuHVVl NU6gqa3kxKlDauTER5msajcgqYVQn1N91T5/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=TcONZsq7g+iY0SG7QHmrfoirYhnuNUTJajb460Rjq0KtSIYuMdAroy3Yd/IO93BFtY 76Ye00zzCgn+S5/Dka6CTXQ7UMr3HSIQDi5jmg+VSMfgxkHpYiKTSfTYSwQ0e/T2Aiys vphxQcQbFfspldP9ytuAemhArvuZqHsBuewb8= Received: by 10.224.76.74 with SMTP id b10mr2612333qak.339.1303137265486; Mon, 18 Apr 2011 07:34:25 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id k2sm4068365qcu.43.2011.04.18.07.34.23 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 07:34:23 -0700 (PDT) Date: Mon, 18 Apr 2011 10:34:16 -0400 From: Alexander Kabaev To: Dimitry Andric Message-ID: <20110418103416.76b07b36@kan.dnsalias.net> In-Reply-To: <4DAC3FD9.1060603@FreeBSD.org> References: <4DAC3FD9.1060603@FreeBSD.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/HE9=aLB=UIM5lkFIXnBIgWp"; protocol="application/pgp-signature" Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:03:45 -0000 --Sig_/HE9=aLB=UIM5lkFIXnBIgWp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 18 Apr 2011 15:42:49 +0200 Dimitry Andric wrote: > Reviving an old thread(*), I would like to propose to finally remove > the Intel C Compiler support from share/mk and other places. As > mentioned in that thread, the ICC bits simply do not work anymore, > and no one has volunteered to fix it for many years. >=20 > Please review the attached patch, which cleans up the ICC bits. >=20 >=20 > *) > http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019179.html You probably also want to remove the code that uses __INTEL_COMPILER in source tree if you want to be really thorough. --=20 Alexander Kabaev --Sig_/HE9=aLB=UIM5lkFIXnBIgWp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFNrEvuQ6z1jMm+XZYRAhS9AJwPqUX6MD4V26T9hBEsNDNNgQAfggCg5Ytr IocLFZW53AauDtA7RQOp/ys= =OEaV -----END PGP SIGNATURE----- --Sig_/HE9=aLB=UIM5lkFIXnBIgWp-- From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 19:47:04 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A19CF1065670; Mon, 18 Apr 2011 19:47:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D4BA58FC14; Mon, 18 Apr 2011 19:47:03 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:adc5:19f9:a31a:3bcd] (unknown [IPv6:2001:7b8:3a7:0:adc5:19f9:a31a:3bcd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DD7FA5C59; Mon, 18 Apr 2011 21:47:02 +0200 (CEST) Message-ID: <4DAC9534.60009@FreeBSD.org> Date: Mon, 18 Apr 2011 21:47:00 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Kabaev References: <4DAC3FD9.1060603@FreeBSD.org> <20110418103416.76b07b36@kan.dnsalias.net> In-Reply-To: <20110418103416.76b07b36@kan.dnsalias.net> Content-Type: multipart/mixed; boundary="------------080709080509050705050302" Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:47:04 -0000 This is a multi-part message in MIME format. --------------080709080509050705050302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2011-04-18 16:34, Alexander Kabaev wrote: ... >> Please review the attached patch, which cleans up the ICC bits. > You probably also want to remove the code that uses __INTEL_COMPILER > in source tree if you want to be really thorough. Ok, new patch attached. Some of the contributed sources also contain instances of __INTEL_COMPILER, but these are all from upstream, so I left them in. --------------080709080509050705050302 Content-Type: text/plain; name="remove-icc-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="remove-icc-2.diff" diff --git a/include/stdbool.h b/include/stdbool.h index c0d6459..c0ce8bb 100644 --- a/include/stdbool.h +++ b/include/stdbool.h @@ -37,7 +37,7 @@ #define true 1 #define bool _Bool -#if __STDC_VERSION__ < 199901L && __GNUC__ < 3 && !defined(__INTEL_COMPILER) +#if __STDC_VERSION__ < 199901L && __GNUC__ < 3 typedef int _Bool; #endif diff --git a/include/stdlib.h b/include/stdlib.h index 3c48f17..c212cde 100644 --- a/include/stdlib.h +++ b/include/stdlib.h @@ -228,7 +228,7 @@ extern void (*_malloc_message)(const char *, const char *, const char *, * programs which use it will fail to link when compiled with non-GNU * compilers. */ -#if __GNUC__ >= 2 || defined(__INTEL_COMPILER) +#if __GNUC__ >= 2 #undef alloca /* some GNU bits try to get cute and define this on their own */ #define alloca(sz) __builtin_alloca(sz) #elif defined(lint) diff --git a/lib/msun/src/math.h b/lib/msun/src/math.h index 8ad13ed..8c229e5 100644 --- a/lib/msun/src/math.h +++ b/lib/msun/src/math.h @@ -34,11 +34,11 @@ extern const union __nan_un { float __uf; } __nan; -#if __GNUC_PREREQ__(3, 3) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 800) +#if __GNUC_PREREQ__(3, 3) #define __MATH_BUILTIN_CONSTANTS #endif -#if __GNUC_PREREQ__(3, 0) && !defined(__INTEL_COMPILER) +#if __GNUC_PREREQ__(3, 0) #define __MATH_BUILTIN_RELOPS #endif diff --git a/share/mk/bsd.cpu.mk b/share/mk/bsd.cpu.mk index 99c28aa..0670bff 100644 --- a/share/mk/bsd.cpu.mk +++ b/share/mk/bsd.cpu.mk @@ -91,31 +91,6 @@ _CPUCFLAGS = -march=prescott . else _CPUCFLAGS = -march=${CPUTYPE} . endif # GCC on 'i386' -. if ${CPUTYPE} == "crusoe" -_ICC_CPUCFLAGS = -tpp6 -xiM -. elif ${CPUTYPE} == "athlon-mp" || ${CPUTYPE} == "athlon-xp" || \ - ${CPUTYPE} == "athlon-4" -_ICC_CPUCFLAGS = -tpp6 -xiMK -. elif ${CPUTYPE} == "athlon-tbird" || ${CPUTYPE} == "athlon" -_ICC_CPUCFLAGS = -tpp6 -xiM -. elif ${CPUTYPE} == "k6-3" || ${CPUTYPE} == "k6-2" || ${CPUTYPE} == "k6" -_ICC_CPUCFLAGS = -tpp6 -xi -. elif ${CPUTYPE} == "k5" -_ICC_CPUCFLAGS = -tpp5 -. elif ${CPUTYPE} == "pentium4" || ${CPUTYPE} == "pentium4m" -_ICC_CPUCFLAGS = -tpp7 -xiMKW -. elif ${CPUTYPE} == "pentium3" || ${CPUTYPE} == "pentium3m" || \ - ${CPUTYPE} == "pentium-m" -_ICC_CPUCFLAGS = -tpp6 -xiMK -. elif ${CPUTYPE} == "pentium2" || ${CPUTYPE} == "pentiumpro" -_ICC_CPUCFLAGS = -tpp6 -xiM -. elif ${CPUTYPE} == "pentium-mmx" -_ICC_CPUCFLAGS = -tpp5 -xM -. elif ${CPUTYPE} == "pentium" -_ICC_CPUCFLAGS = -tpp5 -. else -_ICC_CPUCFLAGS = -. endif # ICC on 'i386' . elif ${MACHINE_CPUARCH} == "amd64" _CPUCFLAGS = -march=${CPUTYPE} . elif ${MACHINE_CPUARCH} == "arm" @@ -242,9 +217,5 @@ CFLAGS += -G0 # NB: COPTFLAGS is handled in /usr/src/sys/conf/kern.pre.mk .if !defined(NO_CPU_CFLAGS) -. if ${CC} == "icc" -CFLAGS += ${_ICC_CPUCFLAGS} -. else CFLAGS += ${_CPUCFLAGS} -. endif .endif diff --git a/share/mk/bsd.dep.mk b/share/mk/bsd.dep.mk index 459a9c3..c452528 100644 --- a/share/mk/bsd.dep.mk +++ b/share/mk/bsd.dep.mk @@ -125,13 +125,8 @@ depend: beforedepend ${DEPENDFILE} afterdepend # Different types of sources are compiled with slightly different flags. # Split up the sources, and filter out headers and non-applicable flags. -.if ${CC:T:Micc} == "icc" -MKDEP_CFLAGS= ${CFLAGS:M-X*} ${CFLAGS:M-[BIDU]*} -MKDEP_CXXFLAGS= ${CXXFLAGS:M-X*} ${CXXFLAGS:M-[BIDU]*} -.else MKDEP_CFLAGS= ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BIDU]*} MKDEP_CXXFLAGS= ${CXXFLAGS:M-nostdinc*} ${CXXFLAGS:M-[BIDU]*} -.endif DPSRCS+= ${SRCS} ${DEPENDFILE}: ${DPSRCS} diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk index 9d655b6..943010c 100644 --- a/share/mk/bsd.lib.mk +++ b/share/mk/bsd.lib.mk @@ -65,11 +65,7 @@ PICFLAG=-fpic .endif .endif -.if ${CC:T:Micc} == "icc" -PO_FLAG=-p -.else PO_FLAG=-pg -.endif .c.po: ${CC} ${PO_FLAG} ${PO_CFLAGS} -c ${.IMPSRC} -o ${.TARGET} diff --git a/share/mk/bsd.sys.mk b/share/mk/bsd.sys.mk index fc5ec40..796d169 100644 --- a/share/mk/bsd.sys.mk +++ b/share/mk/bsd.sys.mk @@ -11,20 +11,18 @@ # the default is gnu99 for now CSTD ?= gnu99 -.if ${CC:T:Micc} != "icc" -. if ${CSTD} == "k&r" +.if ${CSTD} == "k&r" CFLAGS += -traditional -. elif ${CSTD} == "c89" || ${CSTD} == "c90" +.elif ${CSTD} == "c89" || ${CSTD} == "c90" CFLAGS += -std=iso9899:1990 -. elif ${CSTD} == "c94" || ${CSTD} == "c95" +.elif ${CSTD} == "c94" || ${CSTD} == "c95" CFLAGS += -std=iso9899:199409 -. elif ${CSTD} == "c99" +.elif ${CSTD} == "c99" CFLAGS += -std=iso9899:1999 -. else +.else CFLAGS += -std=${CSTD} -. endif .endif -.if !defined(NO_WARNS) && ${CC:T:Micc} != "icc" +.if !defined(NO_WARNS) # -pedantic is problematic because it also imposes namespace restrictions #CFLAGS += -pedantic . if defined(WARNS) @@ -82,9 +80,8 @@ CWARNFLAGS += -Wno-format CWARNFLAGS += -Wno-unknown-pragmas .endif -.if ${MK_SSP} != "no" && ${CC:T:Micc} != "icc" && \ - ${MACHINE_CPUARCH} != "ia64" && \ - ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" +.if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \ + ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" # Don't use -Wstack-protector as it breaks world with -Werror. SSP_CFLAGS ?= -fstack-protector CFLAGS += ${SSP_CFLAGS} diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk index 01b1438..1e58378 100644 --- a/sys/conf/kern.mk +++ b/sys/conf/kern.mk @@ -6,14 +6,9 @@ # Note that the newly added -Wcast-qual is responsible for generating # most of the remaining warnings. Warnings introduced with -Wall will # also pop up, but are easier to fix. -.if ${CC:T:Micc} == "icc" -#CWARNFLAGS= -w2 # use this if you are terribly bored -CWARNFLAGS= -.else CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -Wundef -Wno-pointer-sign -fformat-extensions -.endif # # The following flags are next up for working on: # -W @@ -29,7 +24,7 @@ CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ # operations inside the kernel itself. These operations are exclusively # reserved for user applications. # -.if ${MACHINE_CPUARCH} == "i386" && ${CC:T:Micc} != "icc" +.if ${MACHINE_CPUARCH} == "i386" .if ${CC:T:Mclang} != "clang" CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 .endif @@ -100,22 +95,13 @@ INLINE_LIMIT?= 8000 # GCC 3.0 and above like to do certain optimizations based on the # assumption that the program is linked against libc. Stop this. # -.if ${CC:T:Micc} == "icc" -CFLAGS+= -nolib_inline -.else CFLAGS+= -ffreestanding -.endif - -.if ${CC:T:Micc} == "icc" -CFLAGS+= -restrict -.endif # # GCC SSP support. # -.if ${MK_SSP} != "no" && ${CC:T:Micc} != "icc" && \ - ${MACHINE_CPUARCH} != "ia64" && ${MACHINE_CPUARCH} != "arm" && \ - ${MACHINE_CPUARCH} != "mips" +.if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \ + ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" CFLAGS+= -fstack-protector .endif diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk index 4deaea8..db244c4 100644 --- a/sys/conf/kern.pre.mk +++ b/sys/conf/kern.pre.mk @@ -23,38 +23,25 @@ NM?= nm OBJCOPY?= objcopy SIZE?= size -.if ${CC:T:Micc} == "icc" -COPTFLAGS?= -O -.else -. if defined(DEBUG) +.if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g -. else +.else _MINUS_O= -O2 -. endif -. if ${MACHINE_CPUARCH} == "amd64" +.endif +.if ${MACHINE_CPUARCH} == "amd64" COPTFLAGS?=-O2 -frename-registers -pipe -. else +.else COPTFLAGS?=${_MINUS_O} -pipe -. endif -. if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) +.endif +.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) COPTFLAGS+= -fno-strict-aliasing -. endif .endif .if !defined(NO_CPU_COPTFLAGS) -. if ${CC:T:Micc} == "icc" -COPTFLAGS+= ${_ICC_CPUCFLAGS:C/(-x[^M^K^W]+)[MKW]+|-x[MKW]+/\1/} -. else COPTFLAGS+= ${_CPUCFLAGS} -. endif .endif -.if ${CC:T:Micc} == "icc" -C_DIALECT= -NOSTDINC= -X -.else C_DIALECT= -std=c99 NOSTDINC= -nostdinc -.endif INCLUDES= ${NOSTDINC} ${INCLMAGIC} -I. -I$S @@ -89,36 +76,31 @@ INCLUDES+= -I$S/dev/cxgb -I$S/dev/cxgbe CFLAGS= ${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS} CFLAGS+= ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -.if ${CC:T:Micc} != "icc" .if ${CC:T:Mclang} != "clang" CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT} -.if ${MACHINE_CPUARCH} != "mips" +. if ${MACHINE_CPUARCH} != "mips" CFLAGS+= --param inline-unit-growth=100 CFLAGS+= --param large-function-growth=1000 -.else +. else # XXX Actually a gross hack just for Octeon because of the Simple Executive. CFLAGS+= --param inline-unit-growth=10000 CFLAGS+= --param large-function-growth=100000 CFLAGS+= --param max-inline-insns-single=10000 -.endif +. endif .endif WERROR?= -Werror -.endif # XXX LOCORE means "don't declare C stuff" not "for locore.s". ASM_CFLAGS= -x assembler-with-cpp -DLOCORE ${CFLAGS} .if defined(PROFLEVEL) && ${PROFLEVEL} >= 1 -.if ${CC:T:Micc} == "icc" -.error "Profiling doesn't work with icc" -.endif CFLAGS+= -DGPROF -falign-functions=16 -.if ${PROFLEVEL} >= 2 +. if ${PROFLEVEL} >= 2 CFLAGS+= -DGPROF4 -DGUPROF PROF= -pg -mprofiler-epilogue -.else +. else PROF= -pg -.endif +. endif .endif DEFINED_PROF= ${PROF} diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk index 2239d66..6d22e41 100644 --- a/sys/conf/kmod.mk +++ b/sys/conf/kmod.mk @@ -88,25 +88,17 @@ __KLD_SHARED=yes __KLD_SHARED=no .endif -.if ${CC:T:Micc} == "icc" -CFLAGS:= ${CFLAGS:C/(-x[^M^K^W]+)[MKW]+|-x[MKW]+/\1/} -.else -. if !empty(CFLAGS:M-O[23s]) && empty(CFLAGS:M-fno-strict-aliasing) +.if !empty(CFLAGS:M-O[23s]) && empty(CFLAGS:M-fno-strict-aliasing) CFLAGS+= -fno-strict-aliasing -. endif +.endif WERROR?= -Werror -.endif CFLAGS+= ${WERROR} CFLAGS+= -D_KERNEL CFLAGS+= -DKLD_MODULE # Don't use any standard or source-relative include directories. -.if ${CC:T:Micc} == "icc" -NOSTDINC= -X -.else CSTD= c99 NOSTDINC= -nostdinc -.endif CFLAGS:= ${CFLAGS:N-I*} ${NOSTDINC} ${INCLMAGIC} ${CFLAGS:M-I*} .if defined(KERNBUILDDIR) CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h @@ -121,7 +113,7 @@ CFLAGS+= -I. -I@ # for example. CFLAGS+= -I@/contrib/altq -.if ${CC:T:Micc} != "icc" && ${CC:T:Mclang} != "clang" +.if ${CC:T:Mclang} != "clang" CFLAGS+= -finline-limit=${INLINE_LIMIT} CFLAGS+= --param inline-unit-growth=100 CFLAGS+= --param large-function-growth=1000 @@ -129,9 +121,7 @@ CFLAGS+= --param large-function-growth=1000 # Disallow common variables, and if we end up with commons from # somewhere unexpected, allocate storage for them in the module itself. -.if ${CC:T:Micc} != "icc" CFLAGS+= -fno-common -.endif LDFLAGS+= -d -warn-common CFLAGS+= ${DEBUG_FLAGS} diff --git a/sys/dev/aic7xxx/aicasm/Makefile b/sys/dev/aic7xxx/aicasm/Makefile index c077285..b8352d6 100644 --- a/sys/dev/aic7xxx/aicasm/Makefile +++ b/sys/dev/aic7xxx/aicasm/Makefile @@ -24,12 +24,7 @@ WARNS?= 5 DEPENDFILE= .depend_aicasm .endif -.if ${CC:T:Micc} == "icc" -CFLAGS+= -restrict -NOSTDINC= -X -.else NOSTDINC= -nostdinc -.endif CFLAGS+= ${NOSTDINC} -I/usr/include -I. .ifdef MAKESRCPATH CFLAGS+= -I${MAKESRCPATH} diff --git a/sys/i386/i386/in_cksum.c b/sys/i386/i386/in_cksum.c index c0e92d6..3984049 100644 --- a/sys/i386/i386/in_cksum.c +++ b/sys/i386/i386/in_cksum.c @@ -54,11 +54,7 @@ __FBSDID("$FreeBSD$"); #undef ADDCARRY #define ADDCARRY(x) if ((x) > 0xffff) (x) -= 0xffff -/* - * icc needs to be special cased here, as the asm code below results - * in broken code if compiled with icc. - */ -#if !defined(__GNUCLIKE_ASM) || defined(__INTEL_COMPILER) +#if !defined(__GNUCLIKE_ASM) /* non gcc parts stolen from sys/alpha/alpha/in_cksum.c */ #define REDUCE32 \ { \ @@ -75,7 +71,7 @@ __FBSDID("$FreeBSD$"); #endif #define REDUCE {sum = (sum & 0xffff) + (sum >> 16); ADDCARRY(sum);} -#if !defined(__GNUCLIKE_ASM) || defined(__INTEL_COMPILER) +#if !defined(__GNUCLIKE_ASM) static const u_int32_t in_masks[] = { /*0 bytes*/ /*1 byte*/ /*2 bytes*/ /*3 bytes*/ 0x00000000, 0x000000FF, 0x0000FFFF, 0x00FFFFFF, /* offset 0 */ diff --git a/sys/i386/include/in_cksum.h b/sys/i386/include/in_cksum.h index c692f69..35c6577 100644 --- a/sys/i386/include/in_cksum.h +++ b/sys/i386/include/in_cksum.h @@ -53,7 +53,7 @@ * in the normal case (where there are no options and the header length is * therefore always exactly five 32-bit words. */ -#if defined(__GNUCLIKE_ASM) && !defined(__INTEL_COMPILER) +#if defined(__GNUCLIKE_ASM) static __inline u_int in_cksum_hdr(const struct ip *ip) { @@ -131,7 +131,7 @@ in_pseudo(u_int sum, u_int b, u_int c) #endif #ifdef _KERNEL -#if !defined(__GNUCLIKE_ASM) || defined(__INTEL_COMPILER) +#if !defined(__GNUCLIKE_ASM) u_int in_cksum_hdr(const struct ip *ip); u_short in_addword(u_short sum, u_short b); u_short in_pseudo(u_int sum, u_int b, u_int c); diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index dbab329..15bcfe4 100644 --- a/sys/sys/cdefs.h +++ b/sys/sys/cdefs.h @@ -50,9 +50,9 @@ * having a compiler-agnostic source tree. */ -#if defined(__GNUC__) || defined(__INTEL_COMPILER) +#if defined(__GNUC__) -#if __GNUC__ >= 3 || defined(__INTEL_COMPILER) +#if __GNUC__ >= 3 #define __GNUCLIKE_ASM 3 #define __GNUCLIKE_MATH_BUILTIN_CONSTANTS #else @@ -62,17 +62,11 @@ #define __GNUCLIKE___OFFSETOF 1 #define __GNUCLIKE___SECTION 1 -#ifndef __INTEL_COMPILER -# define __GNUCLIKE_CTOR_SECTION_HANDLING 1 -#endif +#define __GNUCLIKE_CTOR_SECTION_HANDLING 1 #define __GNUCLIKE_BUILTIN_CONSTANT_P 1 -# if defined(__INTEL_COMPILER) && defined(__cplusplus) \ - && __INTEL_COMPILER < 800 -# undef __GNUCLIKE_BUILTIN_CONSTANT_P -# endif -#if (__GNUC_MINOR__ > 95 || __GNUC__ >= 3) && !defined(__INTEL_COMPILER) +#if __GNUC_MINOR__ > 95 || __GNUC__ >= 3 # define __GNUCLIKE_BUILTIN_VARARGS 1 # define __GNUCLIKE_BUILTIN_STDARG 1 # define __GNUCLIKE_BUILTIN_VAALIST 1 @@ -82,10 +76,8 @@ # define __GNUC_VA_LIST_COMPATIBILITY 1 #endif -#ifndef __INTEL_COMPILER -# define __GNUCLIKE_BUILTIN_NEXT_ARG 1 -# define __GNUCLIKE_MATH_BUILTIN_RELOPS -#endif +#define __GNUCLIKE_BUILTIN_NEXT_ARG 1 +#define __GNUCLIKE_MATH_BUILTIN_RELOPS #define __GNUCLIKE_BUILTIN_MEMCPY 1 @@ -101,12 +93,12 @@ #define __CC_SUPPORTS_DYNAMIC_ARRAY_INIT 1 -#endif /* __GNUC__ || __INTEL_COMPILER */ +#endif /* __GNUC__ */ /* * Macro to test if we're using a specific version of gcc or later. */ -#if defined(__GNUC__) && !defined(__INTEL_COMPILER) +#if defined(__GNUC__) #define __GNUC_PREREQ__(ma, mi) \ (__GNUC__ > (ma) || __GNUC__ == (ma) && __GNUC_MINOR__ >= (mi)) #else @@ -187,12 +179,12 @@ #define __aligned(x) #define __section(x) #else -#if !__GNUC_PREREQ__(2, 5) && !defined(__INTEL_COMPILER) +#if !__GNUC_PREREQ__(2, 5) #define __dead2 #define __pure2 #define __unused #endif -#if __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7 && !defined(__INTEL_COMPILER) +#if __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7 #define __dead2 __attribute__((__noreturn__)) #define __pure2 __attribute__((__const__)) #define __unused @@ -207,15 +199,6 @@ #define __aligned(x) __attribute__((__aligned__(x))) #define __section(x) __attribute__((__section__(x))) #endif -#if defined(__INTEL_COMPILER) -#define __dead2 __attribute__((__noreturn__)) -#define __pure2 __attribute__((__const__)) -#define __unused __attribute__((__unused__)) -#define __used __attribute__((__used__)) -#define __packed __attribute__((__packed__)) -#define __aligned(x) __attribute__((__aligned__(x))) -#define __section(x) __attribute__((__section__(x))) -#endif #endif #if __GNUC_PREREQ__(2, 96) @@ -226,7 +209,7 @@ #define __pure #endif -#if __GNUC_PREREQ__(3, 1) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 800) +#if __GNUC_PREREQ__(3, 1) #define __always_inline __attribute__((__always_inline__)) #else #define __always_inline @@ -245,11 +228,11 @@ #endif /* XXX: should use `#if __STDC_VERSION__ < 199901'. */ -#if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) +#if !__GNUC_PREREQ__(2, 7) #define __func__ NULL #endif -#if (defined(__INTEL_COMPILER) || (defined(__GNUC__) && __GNUC__ >= 2)) && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901 +#if (defined(__GNUC__) && __GNUC__ >= 2) && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901 #define __LONG_LONG_SUPPORTED #endif @@ -336,7 +319,7 @@ * that are known to support the features properly (old versions of gcc-2 * didn't permit keeping the keywords out of the application namespace). */ -#if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER) +#if !__GNUC_PREREQ__(2, 7) #define __printflike(fmtarg, firstvararg) #define __scanflike(fmtarg, firstvararg) #define __format_arg(fmtarg) @@ -349,18 +332,16 @@ #endif /* Compiler-dependent macros that rely on FreeBSD-specific extensions. */ -#if __FreeBSD_cc_version >= 300001 && defined(__GNUC__) && !defined(__INTEL_COMPILER) +#if __FreeBSD_cc_version >= 300001 && defined(__GNUC__) #define __printf0like(fmtarg, firstvararg) \ __attribute__((__format__ (__printf0__, fmtarg, firstvararg))) #else #define __printf0like(fmtarg, firstvararg) #endif -#if defined(__GNUC__) || defined(__INTEL_COMPILER) -#ifndef __INTEL_COMPILER +#if defined(__GNUC__) #define __strong_reference(sym,aliassym) \ extern __typeof (sym) aliassym __attribute__ ((__alias__ (#sym))) -#endif #ifdef __STDC__ #define __weak_reference(sym,alias) \ __asm__(".weak " #alias); \ @@ -386,12 +367,12 @@ #define __sym_default(impl,sym,verid) \ __asm__(".symver impl, sym@@verid") #endif /* __STDC__ */ -#endif /* __GNUC__ || __INTEL_COMPILER */ +#endif /* __GNUC__ */ #define __GLOBL1(sym) __asm__(".globl " #sym) #define __GLOBL(sym) __GLOBL1(sym) -#if defined(__GNUC__) || defined(__INTEL_COMPILER) +#if defined(__GNUC__) #define __IDSTRING(name,string) __asm__(".ident\t\"" string "\"") #else /* diff --git a/usr.bin/csup/misc.h b/usr.bin/csup/misc.h index a7ca3a6..9303f4a 100644 --- a/usr.bin/csup/misc.h +++ b/usr.bin/csup/misc.h @@ -60,11 +60,8 @@ #undef __packed #define __packed __attribute__((__packed__)) -/* We explicitely don't define this with icc because it defines __GNUC__ - but doesn't support it. */ #undef __printflike -#if defined(__GNUC__) && !defined(__INTEL_COMPILER) && \ - (__GNUC__ > 2 || __GNUC__ == 2 && __GNUC__MINOR__ >= 7) +#if defined(__GNUC__) && (__GNUC__ > 2 || __GNUC__ == 2 && __GNUC__MINOR__ >= 7) #define __printflike(fmtarg, firstvararg) \ __attribute__((__format__ (__printf__, fmtarg, firstvararg))) #else --------------080709080509050705050302-- From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 11:21:33 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D156C106566B; Tue, 19 Apr 2011 11:21:33 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 844E68FC15; Tue, 19 Apr 2011 11:21:33 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1557F8.dip.t-dialin.net [91.21.87.248]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 648F6844015; Tue, 19 Apr 2011 13:21:18 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 19ECA1CDF; Tue, 19 Apr 2011 13:21:15 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p3JBLEEB085729; Tue, 19 Apr 2011 13:21:14 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 19 Apr 2011 13:21:14 +0200 Message-ID: <20110419132114.43009vpwaeidet68@webmail.leidinger.net> Date: Tue, 19 Apr 2011 13:21:14 +0200 From: Alexander Leidinger To: Dimitry Andric References: <4DAC3FD9.1060603@FreeBSD.org> <20110418103416.76b07b36@kan.dnsalias.net> <4DAC9534.60009@FreeBSD.org> In-Reply-To: <4DAC9534.60009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 648F6844015.AE694 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0, required 6, autolearn=disabled) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1303816878.61879@3G7XlhemNpacWYtsV3GnLA X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:21:33 -0000 Quoting Dimitry Andric (from Mon, 18 Apr 2011 21:47:00 +0200): > On 2011-04-18 16:34, Alexander Kabaev wrote: > ... >>> Please review the attached patch, which cleans up the ICC bits. >> You probably also want to remove the code that uses __INTEL_COMPILER >> in source tree if you want to be really thorough. > > Ok, new patch attached. Some of the contributed sources also contain > instances of __INTEL_COMPILER, but these are all from upstream, so I > left them in. Is it really necessary to remove them from cdefs.h? If someone takes parts of our source and wants to compile them on linux or windows with icc, the icc parts in cdefs.h are a valuable part to have. Info: AFAIR I didn't add icc stuff to csup, and AFAIR csup was added when our icc in the ports collection was outdated, so I assume someone tested csup with icc on linux and addid this stuff there. Removing it from csup seems to be a step backwards to me in this case. Regarding the build infrastructure part I just skimmed over it, and the math/std* headers and 1s-complement-checksum part looks ok to me. Bye, Alexander. -- Intel CPUs are not defective, they just act that way. -- Henry Spencer http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 17:08:28 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45BB11065679 for ; Tue, 19 Apr 2011 17:08:28 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF898FC14 for ; Tue, 19 Apr 2011 17:08:27 +0000 (UTC) Received: by wyf23 with SMTP id 23so6111211wyf.13 for ; Tue, 19 Apr 2011 10:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=12fTYUKZtYHVYuWMxQ2HuVqgMBwL9vrBxQsRVtTbFww=; b=dOish2xL/B+iPU/Tx9LLKkyhA5Mnk27ZTU1VLyR7Yqp/fI18ZmWs/FcFku6oexEhda zZsgYHAzcCFpZKSZKPUXk/2je6Y9T3thzy5BK5WXtFAi6o3ZLx55nVGYzoCERw/erktg orbLdjIUz9EH8dcivpKEotmeY8mdVgMTZB6N8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=AbwP2yp+Nx7tzCTQv7Rl9ENkEEVcZAiO9me7PggU/bqj49t5vHRmJxAbAkFdeaT7Xw 7TYbozMPGaksJee9lwaJpzFLsOMq5wsQIsMbOFZpOEcXVuctXN/cTzD5/iDbFs1oqCbo ohEdbaSCw0B8l00gp63siG0ivqPb73HzjoEu0= MIME-Version: 1.0 Received: by 10.216.59.81 with SMTP id r59mr2595302wec.40.1303232906215; Tue, 19 Apr 2011 10:08:26 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.9.67 with HTTP; Tue, 19 Apr 2011 10:08:26 -0700 (PDT) Date: Tue, 19 Apr 2011 10:08:26 -0700 X-Google-Sender-Auth: sh-gNt94RI4w2Vbyc9xzIvMxMb4 Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch Content-Type: multipart/mixed; boundary=000e0cdff8226f427704a1488eba X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: posix_fallocate(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:08:28 -0000 --000e0cdff8226f427704a1488eba Content-Type: text/plain; charset=ISO-8859-1 The syscall and default VOP are in CURRENT now. I'm attaching the testcase I was using to make sure it was correct, so that work doesn't need to be re-done if anyone wants to work on an implementation of VOP_ALLOCATE for ufs or zfs. I'd like to integrate this into tools/test/posix_fallocate/ but honestly I'm not likely to have the time soon. I intend to try and take care of this at BSDCan when my job responsibilities for the week are to hack on FreeBSD. :-) FYI, the odd format to the code is mostly due to using a few #defines to get this test code that was originally written for $WORK's hack of libcheck to compile and run as a stand-alone. For FreeBSD I've been testing as: cc -o falloc check_posix_fallocate.c -lsbuf ./falloc At $WORK we have a test.mk make addendum, and a few variables set in a make file, and the test is run as: make check Cheers, matthew --000e0cdff8226f427704a1488eba-- From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 17:51:51 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 739EE106566B; Tue, 19 Apr 2011 17:51:51 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 323978FC0C; Tue, 19 Apr 2011 17:51:51 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7533:44c6:1935:7a72] (unknown [IPv6:2001:7b8:3a7:0:7533:44c6:1935:7a72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4CF035C59; Tue, 19 Apr 2011 19:51:49 +0200 (CEST) Message-ID: <4DADCBB4.8060301@FreeBSD.org> Date: Tue, 19 Apr 2011 19:51:48 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110415 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Leidinger References: <4DAC3FD9.1060603@FreeBSD.org> <20110418103416.76b07b36@kan.dnsalias.net> <4DAC9534.60009@FreeBSD.org> <20110419132114.43009vpwaeidet68@webmail.leidinger.net> In-Reply-To: <20110419132114.43009vpwaeidet68@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:51:51 -0000 On 2011-04-19 13:21, Alexander Leidinger wrote: ... >>> You probably also want to remove the code that uses __INTEL_COMPILER >>> in source tree if you want to be really thorough. >> >> Ok, new patch attached. Some of the contributed sources also contain >> instances of __INTEL_COMPILER, but these are all from upstream, so I >> left them in. > > Is it really necessary to remove them from cdefs.h? If someone takes > parts of our source and wants to compile them on linux or windows with > icc, the icc parts in cdefs.h are a valuable part to have. Isn't that the case for the other headers too? Except the in_cksum.[ch] files, where the 'fix' for ICC is apparently not needed at all anymore. > Info: AFAIR I didn't add icc stuff to csup, and AFAIR csup was added > when our icc in the ports collection was outdated, so I assume someone > tested csup with icc on linux and addid this stuff there. Removing it > from csup seems to be a step backwards to me in this case. It used to be in contrib, but was moved to the base system recently. If csup is also ported to e.g. Linux, then it won't make much sense to remove the ICC ifdefs. > Regarding the build infrastructure part I just skimmed over it, and > the math/std* headers and 1s-complement-checksum part looks ok to me. For now, I will just commit the Makefile/*.mk part, and leave most headers as they are. From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 18:50:26 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89406106566C for ; Tue, 19 Apr 2011 18:50:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2408FC16 for ; Tue, 19 Apr 2011 18:50:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C5A6246B46 for ; Tue, 19 Apr 2011 14:50:25 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A81F8A02B for ; Tue, 19 Apr 2011 14:50:25 -0400 (EDT) From: John Baldwin To: arch@freebsd.org Date: Tue, 19 Apr 2011 14:50:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201104191450.23758.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Apr 2011 14:50:25 -0400 (EDT) Cc: Subject: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 18:50:26 -0000 I have various patches to allow PCI-PCI bridges to more properly manage their I/O resource windows. So far it is only ported to x86, but I believe it should not be too hard to enable on other platforms. I've broken the patch down into three patches: 1) Some small cleanup to the rman code. Specifically, change rman_manage_region() to actually honor the rm_start and rm_end constraints on the rman and reject attempts to manage a region that is out of range. This exposed several bugs and the patch includes various places that set rm_end incorrectly (typically to ~0 or ~0u instead of ~0ul). Also, to preserve existing behavior, I've changed rman_init() to set rm_start and rm_end to allow managing the full range (0 to ~0ul) if they are not set by the caller when rman_init() is called. http://people.freebsd.org/~jhb/patches/rman_init.patch 2) Extend the rman and bus_if APIs to add some helper routines for managing resources. Specifically, rman_adjust_resource() allows an existing exclusive resource to grow or shrink one or both ends of a resource so that it has a new range. The PCI-PCI bridge driver uses this to grow an I/O window. At the new-bus level there is a new BUS_ADJUST_RESOURCE() method added to the bus interface that a driver that actually allocates resources (such as nexus(4) on x86) can implement via rman_adjust_resource(). This patch also adds methods to fetch the start and end of the first and last free regions within an rman. I use these last two methods to figure out the smallest amount needed to grow an I/O window when growing is required. Note that this patch only includes bus_adjust_resource support for PCI bridges, busses, and nexus devices on x86. It should not be hard to implement this for other platforms however. http://people.freebsd.org/~jhb/patches/bus_adjust_resource.patch 3) Finally, the last patch actually rototills the resource allocation code in the PCI-PCI bridge driver itself. To aid transition, there is a new kernel option (NEW_PCIB) that must be enabled to use the new code. This can allow us to transition some architectures over until all the other architectures have cuaght up for example. The way this is implemented is that each I/O window allocates is full range of addresses from its parent device. The driver then initializes an rman for each I/O window that is "backed" by the resource allocated from the parent. Resource allocation requests for child devices are allocated from the rman in the associated I/O window, growing the I/O window if necessary. This is very similar to how the ACPI bus driver allocates system resources and then suballocates them to child devices. As with the ACPI driver, this does require that bus_activate_resource() in the parent driver of Host to PCI bridges actually works (on many of the embedded platforms it does not, bus_alloc_resource() checks for RF_ACTIVE and implements the logic directly). I e-mailed patches out to fix this several years ago but they were not tested at the time. Those things will have to be addressed before NEW_PCIB can be used. The other requirement for other platforms is to implement appropriate bus_adjust_resource() methods. I think this should not be too difficult however. In general if a bus driver does not create rmans, it can just pass the request up via bus_generic_adjust_resource(). However, if it creates rmans and a resource belongs to one of its rmans, it should use rman_adjust_resource(). http://people.freebsd.org/~jhb/patches/pcib_window.patch I've already had at least one testing report that this fixes the issues with some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI is enabled as this code re-discovers the original windows and programs them correctly. More testing would be good however. Beyond this I am also hacking on some changes to allow Host to PCI bridge drivers that know what ranges they decode to restrict allocation requests to those ranges (some ACPI systems and MP Tables provide this info). I am also hacking on changes to add support for PCI bus renumbering as well. In general all of my recent PCI hacking can be found in p4 at //depot/projects/pci/.... -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 20 09:08:20 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 551041065670 for ; Wed, 20 Apr 2011 09:08:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D8BCC8FC0C for ; Wed, 20 Apr 2011 09:08:19 +0000 (UTC) Received: by fxm11 with SMTP id 11so434861fxm.13 for ; Wed, 20 Apr 2011 02:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EjMjAb7YEws7yVlEduwNUdpInUu8Z28oim/kfct+C0g=; b=q6b8PE2kp+1UP8oAB7+cjpf3oV5eEc/yn0hn5sjibH7Gl24OPFbdrbRdjQbii+kFhM ag/YtdUPVQtHShYMDcPs8RIKPQ+hf0apeHp5oE6GzbhD4pF/bPj5jiuKtXUYRY5WQi1n AsMj6YcO7xBUXwqWXNjPiMdCJyB5IEAyjtL24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MJ10mhhAKUxY5IrDe1uXHL3YhetusffesMpa6d+N06G5NWjvF7OB6JwpzlGMaYJzsT lAcC9CuAB5mmDcBqYQ5rg65F8FVqPL5E1LRPan8u7e31gjEtAs1Re/6/IR+ALdOxrS+1 ScisWiMwT9uPIN9HInYz4SRgyWuH8Fmwxx11E= Received: by 10.223.1.201 with SMTP id 9mr1795801fag.91.1303288713939; Wed, 20 Apr 2011 01:38:33 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id k5sm208792faa.15.2011.04.20.01.38.32 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 01:38:33 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DAE9B86.8040106@FreeBSD.org> Date: Wed, 20 Apr 2011 11:38:30 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Changing how PCI-PCI bridges do resource allocation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:08:20 -0000 Hi. On 19.04.2011 21:50, John Baldwin wrote: > I've already had at least one testing report that this fixes the issues with > some machines' BIOS clearing the I/O windows on some PCI-PCI bridges when ACPI > is enabled as this code re-discovers the original windows and programs them > correctly. More testing would be good however. I would like this helped my Acer TM6292 which also has alike problems with missing PCIe bridge resources, but unluckily it doesn't. Here is verbose dmesg when my system uses this dirty hack: http://people.freebsd.org/~mav/tm6292_pcie.patch to restore bridges resources to the pre-ACPI state: http://people.freebsd.org/~mav/dmesg.boot.hacks Here is respective `pciconf -lvcb` output: http://people.freebsd.org/~mav/pciconf.hacks Here is dmesg with patches, but without NEW_PCIB: http://people.freebsd.org/~mav/dmesg.boot.olbpcib Here is dmesg with patches with NEW_PCIB: http://people.freebsd.org/~mav/dmesg.boot.newpcib Tell me if you need more info or have more patches to try. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 20 09:15:32 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA5BB106564A; Wed, 20 Apr 2011 09:15:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5408FC0A; Wed, 20 Apr 2011 09:15:32 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155769.dip.t-dialin.net [91.21.87.105]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 65637844015; Wed, 20 Apr 2011 11:15:15 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8B8CB1E07; Wed, 20 Apr 2011 11:15:11 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p3K9FB6D026294; Wed, 20 Apr 2011 11:15:11 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 20 Apr 2011 11:15:10 +0200 Message-ID: <20110420111510.31806jq0ffewdrgo@webmail.leidinger.net> Date: Wed, 20 Apr 2011 11:15:10 +0200 From: Alexander Leidinger To: Dimitry Andric References: <4DAC3FD9.1060603@FreeBSD.org> <20110418103416.76b07b36@kan.dnsalias.net> <4DAC9534.60009@FreeBSD.org> <20110419132114.43009vpwaeidet68@webmail.leidinger.net> <4DADCBB4.8060301@FreeBSD.org> In-Reply-To: <4DADCBB4.8060301@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 65637844015.ADCC7 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.077, required 6, autolearn=disabled, TW_TD 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1303895718.86926@UBtFnLfq1mwvwQFcEk5elA X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:15:32 -0000 Quoting Dimitry Andric (from Tue, 19 Apr 2011 19:51:48 +0200): > On 2011-04-19 13:21, Alexander Leidinger wrote: > ... >>>> You probably also want to remove the code that uses __INTEL_COMPILER >>>> in source tree if you want to be really thorough. >>> >>> Ok, new patch attached. Some of the contributed sources also contain >>> instances of __INTEL_COMPILER, but these are all from upstream, so I >>> left them in. >> >> Is it really necessary to remove them from cdefs.h? If someone takes >> parts of our source and wants to compile them on linux or windows with >> icc, the icc parts in cdefs.h are a valuable part to have. > > Isn't that the case for the other headers too? Except the in_cksum.[ch] > files, where the 'fix' for ICC is apparently not needed at all anymore. The stdbool header is somewhat tied to our system I would say. The math one is AFAIK about building the math lib itself. Just from reading the diff I would assume this could manifest itself by compile errors (duplicate definition). I do not know how valuable it is to build this somewhere else. IMO they can stay in or they can be removed. Both should be easy to debug/redo in case of problems. The cdefs header is differntly in this regard, only for some parts you will get easy to debug error cases, other cases are silent (you don't know where it happens) corruption or bad performance. Bye, Alexander. -- Coming together is a beginning; keeping together is progress; working together is success. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Wed Apr 20 15:33:57 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A640F106566B for ; Wed, 20 Apr 2011 15:33:57 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3CBE18FC0A for ; Wed, 20 Apr 2011 15:33:56 +0000 (UTC) Received: by wyf23 with SMTP id 23so863936wyf.13 for ; Wed, 20 Apr 2011 08:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eXKvpWWeg6iHtvO4FfECOBy3Gd54Py6o1VdGWhQ7oZk=; b=KbE4I21KjKkXJkOGSbH3Y/NwXFbt+eZuzu8dS5nqV+LgQJfhsxB7E2/XtHp3n6Ch+t wUAjP9bFMCAEUIxxmoZ5bgzKyuSmKk41zs6VCHLPyN1aJLsjR7ja4CTkeN7WMlO0cfqp 4NAdyqK4ipbTcKYjSduJpRbBQck/JyxEz3Ng4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=a31KAnN+DCfYAZtWv88iCuIrK1jIL8m6bRd+c3Yuh/vl911mjJXtw43nSDnvlsOyVp /EdsuPYh+ROOS8g+H40ZW4Xmhl7B9bmGV1dJaMUYqAbnq0iwOwXFxOhJq6co3azN/h9Y zB8OZJDCsSryInsZjRul42BLcBg2y7ZWPZC4I= MIME-Version: 1.0 Received: by 10.216.134.207 with SMTP id s57mr7653650wei.25.1303313634996; Wed, 20 Apr 2011 08:33:54 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.9.67 with HTTP; Wed, 20 Apr 2011 08:33:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Apr 2011 08:33:54 -0700 X-Google-Sender-Auth: qjrew7cNUUDBeMx3y4PABdO2h0o Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: posix_fallocate(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:33:57 -0000 Mailing list ate my attachment. See http://people.freebsd.org/~mdf/check_posix_fallocate.c . As an aside, when I post from gmail.com to the mailing lists, I don't see a copy of my message. Is this a feature of the litserv, where it doesn't mail it back to the originator, or a "feature" of gmail where it tries to be clever? The problem is that when the list eats an attachment I don't know until someone takes the time to email me, and I'd rather be able to tell immediately. Thanks, matthew On Tue, Apr 19, 2011 at 10:08 AM, wrote: > The syscall and default VOP are in CURRENT now. > > I'm attaching the testcase I was using to make sure it was correct, so > that work doesn't need to be re-done if anyone wants to work on an > implementation of VOP_ALLOCATE for ufs or zfs. =A0I'd like to integrate > this into tools/test/posix_fallocate/ but honestly I'm not likely to > have the time soon. =A0I intend to try and take care of this at BSDCan > when my job responsibilities for the week are to hack on FreeBSD. :-) > > FYI, the odd format to the code is mostly due to using a few #defines > to get this test code that was originally written for $WORK's hack of > libcheck to compile and run as a stand-alone. =A0For FreeBSD I've been > testing as: > > cc -o falloc check_posix_fallocate.c -lsbuf > ./falloc > > At $WORK we have a test.mk make addendum, and a few variables set in a > make file, and the test is run as: > > make check > > Cheers, > matthew > From owner-freebsd-arch@FreeBSD.ORG Wed Apr 20 16:38:10 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8387A106566C; Wed, 20 Apr 2011 16:38:10 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA80A8FC08; Wed, 20 Apr 2011 16:38:09 +0000 (UTC) Received: by wyf23 with SMTP id 23so933088wyf.13 for ; Wed, 20 Apr 2011 09:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wKlIt93fw5/FVwiPyiAWDpM/JN8SRc/Na5hSDYZ8sy8=; b=r5wpjPwSMLFFCbSPTnKOIXvW6pMfF36jLBCNcTMpUrrXwR6j/tKCRyKEU23+CBs7Wq bMnmv7fBN72W4EBHXnOTwNhOJiz5JTn3uCqd88u77YWkDHpROHlSTSNU2LsO2HpG0pUa Jv+MNIMfIQ3/X9Yu2dxQJJyGICMtV0eFuU0cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MhmmT2bAdamijkZKyw0aRhw6D9cL0xioeV46tADFEIBET1DLrJRTVy+p2EhY8UOPjv J4fT1nXYsUtxi1pdsn1P+BRnK94tFHpzN9aB1vNN32tXmvmBCX3dEJCdZvEvoyRs3hal 78JPdBDj4ctmR0ufVuEz4h34HTVT95lxEiB/Y= MIME-Version: 1.0 Received: by 10.216.67.135 with SMTP id j7mr1073420wed.54.1303316051986; Wed, 20 Apr 2011 09:14:11 -0700 (PDT) Received: by 10.216.19.13 with HTTP; Wed, 20 Apr 2011 09:14:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Apr 2011 11:14:11 -0500 Message-ID: From: Brandon Gooch To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: posix_fallocate(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 16:38:10 -0000 On Wed, Apr 20, 2011 at 10:33 AM, wrote: > Mailing list ate my attachment. > > See http://people.freebsd.org/~mdf/check_posix_fallocate.c . > > As an aside, when I post from gmail.com to the mailing lists, I don't > see a copy of my message. =A0Is this a feature of the litserv, where it > doesn't mail it back to the originator, or a "feature" of gmail where > it tries to be clever? =A0The problem is that when the list eats an > attachment I don't know until someone takes the time to email me, and > I'd rather be able to tell immediately. > > Thanks, > matthew > Could it be the mailing list options? From: http://www.gnu.org/software/mailman/mailman-member/node42.html ... set myposts on set myposts off Use `set myposts off' to avoid receiving copies of messages you post to the list. This has no effect if you're receiving digests. ... -Brandon From owner-freebsd-arch@FreeBSD.ORG Thu Apr 21 20:46:37 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736F1106566C; Thu, 21 Apr 2011 20:46:37 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D1B0E8FC15; Thu, 21 Apr 2011 20:46:36 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p3LKX4Ze091423; Thu, 21 Apr 2011 22:33:05 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p3LKX4qP091422; Thu, 21 Apr 2011 22:33:04 +0200 (CEST) (envelope-from marius) Date: Thu, 21 Apr 2011 22:33:04 +0200 From: Marius Strobl To: arch@freebsd.org, net@freebsd.org Message-ID: <20110421203304.GA91381@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC further mii(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:46:37 -0000 Hi, with the addition of mii_attach() and fleshing out the generic flow control I've pretty much brought the FreeBSD mii(4) in line with NetBSD and OpenBSD as much as can be done without breaking the API or ABI, resulting in changes that could be MFC'ed. As you're probably aware however, especially NetBSD fixed and improved their mii(4) over time since it was initially ported to FreeBSD. I think now that stable/7 is basically closed as 7.4 was the last release based on it, 9.0 being right around the corner and probably also only 2-3 further releases being based on stable/8 I think now is actually a good time to incorporate that work and commit any other ABI/API-breaking changes to mii(4). I've prepared a patch which merges all relevant changes from NetBSD I'm ware of and implements some other stuff I had in mind: http://people.freebsd.org/~marius/mii_abi_breaking.diff A list of the anticipated changes is below. The most painful change likely is the fix for the OUI bit reversion problem, which on one hand once again allows us to mostly share miidevs with NetBSD but on the other hand won't allow us to MFC updates of this file verbatim to the existing stable branches in the future (IIRC at least imp@ also was in favor for fixing this bug at some point in time though). An earlier version of this patch was already reviewed by yongari@ (support for setting BMCR_LOOP/MIIF_NOLOOP was removed completely instead of extended and some entries in miidevs fixed, both based on his feedback). If there are no objections I'll commit these changes on April 30th. - Remove attempts to implement setting of BMCR_LOOP/MIIF_NOLOOP (reporting IFM_LOOP based on BMCR_LOOP is left in place though as it might provide useful for debugging). For most mii(4) drivers it was unclear whether the PHYs driven by them actually support loopback or not. Moreover, typically loopback mode also needs to be activated on the MAC, which none of the Ethernet drivers using mii(4) implements. Given that loopback media has no real use (and obviously hardly had a chance to actually work) besides for driver development (which just loopback mode should be sufficient for though, i.e one doesn't necessary need support for loopback media) support for it is just dropped as both NetBSD and OpenBSD already did quite some time ago. - Let mii_phy_add_media() also announce the support of IFM_NONE. - Restructure the PHY entry points to use a structure of entry points instead of discrete function pointers, and extend this to include a "reset" entry point. Make sure any PHY-specific reset routine is always used, and provide one for lxtphy(4) which disables MII interrupts (as is done for a few other PHYs we have drivers for). This includes changing NIC drivers which previously just called the generic mii_phy_reset() to now actually call the PHY-specific reset routine, which might be crucial in some cases. While at it, the redundant checks in these NIC drivers for mii->mii_instance not being zero before calling the reset routines were removed because as soon as one PHY driver attaches mii->mii_instance is incremented and we hardly can end up in their media change callbacks etc if no PHY driver has attached as mii_attach() would have failed in that case and not attach a miibus(4) instance. Consequently, NIC drivers now no longer should call mii_phy_reset() directly, so it was removed from EXPORT_SYMS. - Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe(). The purpose of that function is to perform the common steps to attach a PHY driver instance and to hook it up to the miibus(4) instance and to optionally also handle the probing, addition and initialization of the supported media. So all a PHY driver without any special requirements has to do in its bus attach method is to call mii_phy_dev_attach() along with PHY-specific MIIF_* flags, a pointer to its PHY functions and the add_media set to one. All PHY drivers were updated to take advantage of mii_phy_dev_attach() as appropriate. Along with these changes the capability mask was added to the mii_softc structure so PHY drivers taking advantage of mii_phy_dev_attach() but still handling media on their own do not need to fiddle with the MII attach arguments anyway. - Keep track of the PHY offset in the mii_softc structure. This is done for compatibility with NetBSD/OpenBSD. - Keep track of the PHY's OUI, model and revision in the mii_softc structure. Several PHY drivers require this information also after attaching and previously had to wrap their own softc around mii_softc. NetBSD/OpenBSD also keep track of the model and revision on their mii_softc structure. All PHY drivers were updated to take advantage as appropriate. - Convert the mebers of the MII data structure to unsigned where appropriate. This is partly inspired by NetBSD/OpenBSD. - According to IEEE 802.3-2002 the bits actually have to be reversed when mapping an OUI to the MII ID registers. All PHY drivers and miidevs where changed as necessary. Actually this now again allows to largely share miidevs with NetBSD, which fixed this problem already 9 years ago. Consequently miidevs was synced as far as possible. - Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that weren't explicitly converted to support flow control before. It's unclear whether flow control actually works with these but typically it should and their net behavior should be more correct with these changes in place than without if the MAC driver sets MIIF_DOPAUSE. Marius From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 10:07:16 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2004106566B; Fri, 22 Apr 2011 10:07:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 42E518FC13; Fri, 22 Apr 2011 10:07:16 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CCBEE25D37C7; Fri, 22 Apr 2011 10:07:14 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1568D159D780; Fri, 22 Apr 2011 10:07:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id NbidSIneQdIr; Fri, 22 Apr 2011 10:07:13 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C8AEF159D770; Fri, 22 Apr 2011 10:07:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110421203304.GA91381@alchemy.franken.de> Date: Fri, 22 Apr 2011 10:07:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110421203304.GA91381@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: arch@freebsd.org, net@freebsd.org Subject: Re: RFC further mii(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 10:07:16 -0000 On Apr 21, 2011, at 8:33 PM, Marius Strobl wrote: Hi, I fear the change is too big for me to review currently. One thing I am still pondering is whether we would be able to reserve = enough spares (wherever needed) to be able to eventually allow to = query-through and gather a lot more information than we currently expose = via ifconfig. It would be really great to be able to ask for all the = bits. Not sure how linux for example handles that for mii-tool/ethtool = or how those things work, but .. well you get it. I should not forget to mention that I think what you are trying to do in = harmonizing things currently is excellent progress! Bjoern --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 12:09:11 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84228106564A; Fri, 22 Apr 2011 12:09:11 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D484B8FC19; Fri, 22 Apr 2011 12:09:10 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p3MC99j8002405; Fri, 22 Apr 2011 14:09:09 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p3MC99xW002404; Fri, 22 Apr 2011 14:09:09 +0200 (CEST) (envelope-from marius) Date: Fri, 22 Apr 2011 14:09:09 +0200 From: Marius Strobl To: "Bjoern A. Zeeb" Message-ID: <20110422120909.GO38455@alchemy.franken.de> References: <20110421203304.GA91381@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, net@freebsd.org Subject: Re: RFC further mii(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:09:11 -0000 On Fri, Apr 22, 2011 at 10:07:11AM +0000, Bjoern A. Zeeb wrote: > On Apr 21, 2011, at 8:33 PM, Marius Strobl wrote: > > Hi, Hi > > I fear the change is too big for me to review currently. Given that the majority of changes break backwards compatibility in some way I intend to comitting them in one pass rather than splitting them up, which unfortunately results in a rather large patch ... > > One thing I am still pondering is whether we would be able to reserve enough spares (wherever needed) to be able to eventually allow to query-through and gather a lot more information than we currently expose via ifconfig. It would be really great to be able to ask for all the bits. Not sure how linux for example handles that for mii-tool/ethtool or how those things work, but .. well you get it. > Providing functionality akin mii-tool/ethtool is also something I'd like to see. Unfortunately, I currently lack the time to work on that, maybe next year as a GSoC or some such, in case someone is willing to mentor this time :) However, I think when going a route similar to pci(4)/pciconf(8) (without repeating their mistakes) it should be possible to implement that without breaking the ABI. Marius From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 14:22:22 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8230A106566C; Fri, 22 Apr 2011 14:22:22 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7E48FC0C; Fri, 22 Apr 2011 14:22:22 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 07:10:21 -0700 From: Ben Hutchings To: Marius Strobl In-Reply-To: <20110422120909.GO38455@alchemy.franken.de> References: <20110421203304.GA91381@alchemy.franken.de> <20110422120909.GO38455@alchemy.franken.de> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Date: Fri, 22 Apr 2011 15:10:14 +0100 Message-ID: <1303481415.4129.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2011 14:10:21.0905 (UTC) FILETIME=[047BDC10:01CC00F7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18088.005 X-TM-AS-Result: No--20.306500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Bjoern A. Zeeb" , net@freebsd.org, arch@freebsd.org Subject: Re: RFC further mii(4) changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:22:22 -0000 On Fri, 2011-04-22 at 14:09 +0200, Marius Strobl wrote: > On Fri, Apr 22, 2011 at 10:07:11AM +0000, Bjoern A. Zeeb wrote: [...] > > One thing I am still pondering is whether we would be able to reserve enough spares (wherever needed) to be able to eventually allow to query-through and gather a lot more information than we currently expose via ifconfig. It would be really great to be able to ask for all the bits. Not sure how linux for example handles that for mii-tool/ethtool or how those things work, but .. well you get it. > > > > Providing functionality akin mii-tool/ethtool is also something I'd > like to see. Unfortunately, I currently lack the time to work on that, > maybe next year as a GSoC or some such, in case someone is willing to > mentor this time :) However, I think when going a route similar to > pci(4)/pciconf(8) (without repeating their mistakes) it should be > possible to implement that without breaking the ABI. mii-tool uses the MDIO ioctls, wherease ethtool uses the relatively high-level ethtool API. Note that mii-tool itself is unmaintained and needs some unofficial patches to support even 1G PHYs. The MDIO ioctls all use struct ifreq with an instance of struct mii_ioctl_data in the ifr_ifru field. See and . SIOCGMIIPHY: Set the phy_id field to the address of the PHY that the net device is using. (It is not specified what to do if the device is not using an MDIO-manageable PHY.) SIOCGMIIREG: Read the register at the address specified by phy_id and reg_num. Set val_out to the register value. SIOCSMIIREG: Write the register at the addres specified by phy_id and reg_num, with the value from val_in. For clause 45 MDIO (as used by 10G and some other PHYs), the phy_id for SIOC{G,S}MIIREG (but not SIOCGMIIPHY) provides both PRT and DEV addresses, as specified in . Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 23:35:10 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50D1F106564A for ; Fri, 22 Apr 2011 23:35:10 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA918FC15 for ; Fri, 22 Apr 2011 23:35:09 +0000 (UTC) Received: by pzk27 with SMTP id 27so634441pzk.13 for ; Fri, 22 Apr 2011 16:35:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.38 with SMTP id h6mr2249815pbh.422.1303515309681; Fri, 22 Apr 2011 16:35:09 -0700 (PDT) Received: by 10.68.54.138 with HTTP; Fri, 22 Apr 2011 16:35:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Apr 2011 16:35:09 -0700 Message-ID: From: Gordon Tetlow To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: posix_fallocate(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 23:35:10 -0000 On Wed, Apr 20, 2011 at 8:33 AM, wrote: > As an aside, when I post from gmail.com to the mailing lists, I don't > see a copy of my message. =A0Is this a feature of the litserv, where it > doesn't mail it back to the originator, or a "feature" of gmail where > it tries to be clever? =A0The problem is that when the list eats an > attachment I don't know until someone takes the time to email me, and > I'd rather be able to tell immediately. I believe gmail deduplicates based on message-id, so since it is in your sent items, you won't see it in your inbox. Gordon From owner-freebsd-arch@FreeBSD.ORG Sat Apr 23 20:42:30 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FE2D106564A for ; Sat, 23 Apr 2011 20:42:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 384DE8FC17 for ; Sat, 23 Apr 2011 20:42:29 +0000 (UTC) Received: by qyk27 with SMTP id 27so814941qyk.13 for ; Sat, 23 Apr 2011 13:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=krBQugtID9gLbnOXRxRZMwBz9WRJhTfqcwkPG0YrBaE=; b=kWoG1+/CBflfZUGteArh9S6t5+oozmHOVz8Jt6LsmgYEacwkH7UuMGbHyoaLdO/Yn/ jyC58wesiysJDLcOXyGXfQteGp0weqORYW7OpunUGb9x9L8bvyx1LN1yHhO7yis4NiEj QvatDhOf/jlUb4vhwXnslvVsxK3KWxoaIKwkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ki44CCkn+v3+gOYnODYeLgfeRk5X7wF6VZsWNbAo1+Y8/po4ZaLP1k7zxGuRx7ksyd Pg/WifR6jDL49fo9afLU3VTxwbgInxajNUsQzD3qhrogXFNTna+nPNzfMbnZpwU+y5H7 3EXZBabbjVAm1VBBD5HoAAbay38+w0N2+Jn2Q= MIME-Version: 1.0 Received: by 10.229.67.66 with SMTP id q2mr1694966qci.282.1303589992818; Sat, 23 Apr 2011 13:19:52 -0700 (PDT) Received: by 10.229.221.136 with HTTP; Sat, 23 Apr 2011 13:19:52 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Apr 2011 00:19:52 +0400 Message-ID: From: Sergey Kandaurov To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: posix_fallocate(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 20:42:30 -0000 On 20 April 2011 19:33, wrote: > As an aside, when I post from gmail.com to the mailing lists, I don't > see a copy of my message. =A0Is this a feature of the litserv, where it > doesn't mail it back to the originator, or a "feature" of gmail where > it tries to be clever? =A0The problem is that when the list eats an > attachment I don't know until someone takes the time to email me, and > I'd rather be able to tell immediately. I use gmail and do receive my own messages (I never saw such problem). I checked to receive my own posts to the list in Mailman Subscription Options at lists.freebsd.org. Maybe that's your answer. --=20 wbr, pluknet