From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 16:53:55 2009 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 082D71065670; Sun, 11 Jan 2009 16:53:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BEA318FC1F; Sun, 11 Jan 2009 16:53:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0BGonkF047999; Sun, 11 Jan 2009 09:50:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 11 Jan 2009 09:51:09 -0700 (MST) Message-Id: <20090111.095109.-1112748421.imp@bsdimp.com> To: ru@freebsd.org, arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Quick hack to make fast kernel builds easier 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: Sun, 11 Jan 2009 16:53:56 -0000 This patch makes make buildkernel -DKERNFAST a short cut for make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND which is a lot shorter to type. comments? Warner Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 186807) +++ Makefile.inc1 (working copy) @@ -5,6 +5,7 @@ # -DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir # -DNO_CLEAN do not clean at all # -DNO_SHARE do not go into share subdir +# -DKERNFAST define NO_KERNELCONFIG, NO_KERNELCLEAN and NO_KERNELCONFIG # -DNO_KERNELCONFIG do not run config in ${MAKE} buildkernel # -DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} buildkernel # -DNO_KERNELDEPEND do not run ${MAKE} depend in ${MAKE} buildkernel @@ -697,6 +699,11 @@ # be set to cross-build, we have to make sure TARGET is set # properly. +.if defined(KERNFAST) +NO_KERNELCLEAN= t +NO_KERNELCONFIG= t +NO_KERNELDEPEND= t +.endif .if !defined(KERNCONF) && defined(KERNEL) KERNCONF= ${KERNEL} KERNWARN= From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 17:04:26 2009 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 833B11065687; Sun, 11 Jan 2009 17:04:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 27EE48FC12; Sun, 11 Jan 2009 17:04:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LM3jb-000Nma-MK; Sun, 11 Jan 2009 19:04:23 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0BH4KEb092830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 19:04:21 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0BH4KwA070750; Sun, 11 Jan 2009 19:04:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0BH4KAj070748; Sun, 11 Jan 2009 19:04:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 11 Jan 2009 19:04:20 +0200 From: Kostik Belousov To: "M. Warner Losh" Message-ID: <20090111170420.GV93900@deviant.kiev.zoral.com.ua> References: <20090111.095109.-1112748421.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4hvAEPussNf0ZjKL" Content-Disposition: inline In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LM3jb-000Nma-MK c7d16ce30af6c33b80032d2df1302705 X-Terabit: YES Cc: arch@freebsd.org Subject: Re: Quick hack to make fast kernel builds easier 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: Sun, 11 Jan 2009 17:04:26 -0000 --4hvAEPussNf0ZjKL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2009 at 09:51:09AM -0700, M. Warner Losh wrote: > This patch makes >=20 > make buildkernel -DKERNFAST >=20 > a short cut for >=20 > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND >=20 > which is a lot shorter to type. >=20 > comments? Nice and useful. I have 3x-DNO_... scripted in several places, this options would reduce my typing when I do make by hands. --4hvAEPussNf0ZjKL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklqJpMACgkQC3+MBN1Mb4hHpACg7vbI0J4cTRbSTMChlxSPHlEZ PRsAnjV+HCIXdY1gaXYePyRM8xtFXb64 =8MrO -----END PGP SIGNATURE----- --4hvAEPussNf0ZjKL-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 17:24:29 2009 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 33736106566C; Sun, 11 Jan 2009 17:24:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id BC7CD8FC31; Sun, 11 Jan 2009 17:24:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 4BC781D1A5; Sun, 11 Jan 2009 18:24:27 +0100 (CET) Date: Sun, 11 Jan 2009 18:24:27 +0100 From: Ed Schouten To: "M. Warner Losh" Message-ID: <20090111172427.GD89178@hoeg.nl> References: <20090111.095109.-1112748421.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Km1U/tdNT/EmXiR1" Content-Disposition: inline In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@freebsd.org Subject: Re: Quick hack to make fast kernel builds easier 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: Sun, 11 Jan 2009 17:24:29 -0000 --Km1U/tdNT/EmXiR1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * M. Warner Losh wrote: > This patch makes >=20 > make buildkernel -DKERNFAST >=20 > a short cut for >=20 > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND >=20 > which is a lot shorter to type. Why not call it: make buildkernel -DOIT Seriously: Please commit this. I often just run `make' in /usr/obj/..., which also saves some typing, but unfortunately that doesn't work when cross compiling. --=20 Ed Schouten WWW: http://80386.nl/ --Km1U/tdNT/EmXiR1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklqK0sACgkQ52SDGA2eCwUohQCfRe89WGBFqxIj7DYO8X5LIgdt fwgAn0+JOFkNlBonXm5J9+XsT+aN40/R =pojx -----END PGP SIGNATURE----- --Km1U/tdNT/EmXiR1-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 18:31:51 2009 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 778F91065670; Sun, 11 Jan 2009 18:31:51 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 517C58FC08; Sun, 11 Jan 2009 18:31:51 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id n0BI81es045432; Sun, 11 Jan 2009 10:08:02 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n0BI7qj6053655; Sun, 11 Jan 2009 10:07:52 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from [172.16.1.200] (cpe-68-175-68-135.nyc.res.rr.com [68.175.68.135]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.3) with ESMTP id n0BI7pKw095206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Jan 2009 10:07:52 -0800 (PST) (envelope-from gnn@neville-neil.com) Message-Id: <80B0FC55-BCC9-4971-84F7-5838D6892EC1@neville-neil.com> From: George Neville-Neil To: "M. Warner Losh" In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27--13000171" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 11 Jan 2009 13:07:50 -0500 References: <20090111.095109.-1112748421.imp@bsdimp.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.00 () [Tag at 5.00] X-CanItPRO-Stream: default X-Canit-Stats-ID: 2984114 - c11eaa9477a4 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: arch@freebsd.org Subject: Re: Quick hack to make fast kernel builds easier 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: Sun, 11 Jan 2009 18:31:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-27--13000171 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jan 11, 2009, at 11:51 , M. Warner Losh wrote: > This patch makes > > make buildkernel -DKERNFAST > > a short cut for > > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND > > which is a lot shorter to type. > > comments? > Looks great to me. Later, George --Apple-Mail-27--13000171 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAklqNXYACgkQYdh2wUQKM9LOYACg0GXqapFlL6XA4OmFH2C59zA1 IwsAoLsOJ1hA/IawA0RxTgBoX0OE/Dd6 =fbGr -----END PGP SIGNATURE----- --Apple-Mail-27--13000171-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 19:22:32 2009 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 5D93D106564A for ; Sun, 11 Jan 2009 19:22:32 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 1E36F8FC1E for ; Sun, 11 Jan 2009 19:22:31 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n0BJCpRT074522; Sun, 11 Jan 2009 14:12:51 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n0BJCpkS074521; Sun, 11 Jan 2009 14:12:51 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sun, 11 Jan 2009 14:12:51 -0500 From: David Schultz To: Ed Schouten Message-ID: <20090111191251.GA74450@zim.MIT.EDU> Mail-Followup-To: Ed Schouten , "M. Warner Losh" , arch@FreeBSD.ORG References: <20090111.095109.-1112748421.imp@bsdimp.com> <20090111172427.GD89178@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090111172427.GD89178@hoeg.nl> Cc: arch@FreeBSD.ORG Subject: Re: Quick hack to make fast kernel builds easier 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: Sun, 11 Jan 2009 19:22:32 -0000 On Sun, Jan 11, 2009, Ed Schouten wrote: > I often just run `make' in /usr/obj/..., > which also saves some typing, but unfortunately that doesn't work when > cross compiling. Also, as far as I know, there's no convenient way to rebuild a single module for another architecture. I use the following script called 'arch' to set the appropriate environment variables, so if I've already run 'make universe' and I want to rebuild libc for sparc64, I say: cd /usr/src/lib/libc && arch sparc64 make It would be nice if there were a better mechanism for this that's integrated into the build system. #!/bin/sh arch=$1 basepath=/usr/src export __MAKE_CONF=/dev/null export MAKEOBJDIRPREFIX=/usr/obj/${arch} export MACHINE_ARCH=${arch} export MACHINE=${arch} export CPUTYPE= export GROFF_BIN_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin export GROFF_FONT_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/groff_font export GROFF_TMAC_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/tmac export _SHLIBDIRPREFIX=/usr/obj/${arch}${basepath}/tmp export INSTALL="sh /usr/src/tools/install.sh" export PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/sbin:/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin:/usr/obj/${arch}${basepath}/legacy/usr/games:/usr/obj/${arch}${basepath}/tmp/usr/sbin:/usr/obj/${arch}${basepath}/tmp/usr/bin:/usr/obj/${arch}${basepath}/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin DESTDIR=/usr/obj/${arch}${basepath}/tmp shift $* From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 21:27:53 2009 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 659F310656C2; Sun, 11 Jan 2009 21:27:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 087EC8FC16; Sun, 11 Jan 2009 21:27:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0BLNUI1050885; Sun, 11 Jan 2009 14:23:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 11 Jan 2009 14:23:50 -0700 (MST) Message-Id: <20090111.142350.1560738814.imp@bsdimp.com> To: das@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090111191251.GA74450@zim.MIT.EDU> References: <20090111.095109.-1112748421.imp@bsdimp.com> <20090111172427.GD89178@hoeg.nl> <20090111191251.GA74450@zim.MIT.EDU> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ed@80386.nl, arch@FreeBSD.org Subject: Re: Quick hack to make fast kernel builds easier 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: Sun, 11 Jan 2009 21:27:54 -0000 In message: <20090111191251.GA74450@zim.MIT.EDU> David Schultz writes: : On Sun, Jan 11, 2009, Ed Schouten wrote: : > I often just run `make' in /usr/obj/..., : > which also saves some typing, but unfortunately that doesn't work when : > cross compiling. : : Also, as far as I know, there's no convenient way to rebuild a : single module for another architecture. I use the following script : called 'arch' to set the appropriate environment variables, so if : I've already run 'make universe' and I want to rebuild libc for : sparc64, I say: : : cd /usr/src/lib/libc && arch sparc64 make : : It would be nice if there were a better mechanism for this that's : integrated into the build system. I do one of the following: (1) env TARGET=arm make buildworld -DNO_CLEAN or (2) env TARGET=arm make buildenv $ cd lib/libc && make These both work out well enough in practice for me. I've wanted a target that was 'reworld' that just did an 'all' and maybe a few other things, but I've never had the time to polish this up (had it in a couple of trees that I lost due to disk failure). I do agree it would be nice if there was some way to do 'all' for a subdirectory with a 'trust me, I know what I'm doing, so don't do all that other stuff' flag. Warner : #!/bin/sh : : arch=$1 : basepath=/usr/src : : export __MAKE_CONF=/dev/null : export MAKEOBJDIRPREFIX=/usr/obj/${arch} : export MACHINE_ARCH=${arch} : export MACHINE=${arch} : export CPUTYPE= : export GROFF_BIN_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin : export GROFF_FONT_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/groff_font : export GROFF_TMAC_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/tmac : export _SHLIBDIRPREFIX=/usr/obj/${arch}${basepath}/tmp : export INSTALL="sh /usr/src/tools/install.sh" : export PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/sbin:/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin:/usr/obj/${arch}${basepath}/legacy/usr/games:/usr/obj/${arch}${basepath}/tmp/usr/sbin:/usr/obj/${arch}${basepath}/tmp/usr/bin:/usr/obj/${arch}${basepath}/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin : DESTDIR=/usr/obj/${arch}${basepath}/tmp : : shift : $* : : From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 21:45:01 2009 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 B865F1065688 for ; Sun, 11 Jan 2009 21:45:01 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 85BC08FC16 for ; Sun, 11 Jan 2009 21:45:01 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n0BLYPtr096693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 13:34:26 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <496A65E1.5030309@freebsd.org> Date: Sun, 11 Jan 2009 13:34:25 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090111.095109.-1112748421.imp@bsdimp.com> <20090111172427.GD89178@hoeg.nl> <20090111191251.GA74450@zim.MIT.EDU> <20090111.142350.1560738814.imp@bsdimp.com> In-Reply-To: <20090111.142350.1560738814.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: arch@freebsd.org Subject: Re: Quick hack to make fast kernel builds easier [really cross-build support] 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: Sun, 11 Jan 2009 21:45:02 -0000 M. Warner Losh wrote: > In message: <20090111191251.GA74450@zim.MIT.EDU> > David Schultz writes: > : On Sun, Jan 11, 2009, Ed Schouten wrote: > : > I often just run `make' in /usr/obj/..., > : > which also saves some typing, but unfortunately that doesn't work when > : > cross compiling. > : > : Also, as far as I know, there's no convenient way to rebuild a > : single module for another architecture. I use the following script > : called 'arch' to set the appropriate environment variables, so if > : I've already run 'make universe' and I want to rebuild libc for > : sparc64, I say: > : > : cd /usr/src/lib/libc && arch sparc64 make > : > : It would be nice if there were a better mechanism for this that's > : integrated into the build system. > > I do one of the following: > > (1) env TARGET=arm make buildworld -DNO_CLEAN > > or > > (2) env TARGET=arm make buildenv > $ cd lib/libc && make > > These both work out well enough in practice for me. I've wanted a > target that was 'reworld' that just did an 'all' and maybe a few other > things, but I've never had the time to polish this up (had it in a > couple of trees that I lost due to disk failure). > > I do agree it would be nice if there was some way to do 'all' for a > subdirectory with a 'trust me, I know what I'm doing, so don't do all > that other stuff' flag. > > I told das privately but will note publicly that: tools/tools/nanobsd/gateworks uses make buildenv to cross-build various bits. At some point I want to promote some of the shell code to be part of nanobsd but until we've got something to deal with ports I'm in no hurry. Sam From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 21:47:52 2009 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 44DEB106566B; Sun, 11 Jan 2009 21:47:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 01FD78FC0C; Sun, 11 Jan 2009 21:47:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0BLj3b4051162; Sun, 11 Jan 2009 14:45:03 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 11 Jan 2009 14:45:24 -0700 (MST) Message-Id: <20090111.144524.235773790.imp@bsdimp.com> To: sam@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <496A65E1.5030309@freebsd.org> References: <20090111191251.GA74450@zim.MIT.EDU> <20090111.142350.1560738814.imp@bsdimp.com> <496A65E1.5030309@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Quick hack to make fast kernel builds easier [really cross-build support] 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: Sun, 11 Jan 2009 21:47:52 -0000 In message: <496A65E1.5030309@freebsd.org> Sam Leffler writes: : M. Warner Losh wrote: : > In message: <20090111191251.GA74450@zim.MIT.EDU> : > David Schultz writes: : > : On Sun, Jan 11, 2009, Ed Schouten wrote: : > : > I often just run `make' in /usr/obj/..., : > : > which also saves some typing, but unfortunately that doesn't work when : > : > cross compiling. : > : : > : Also, as far as I know, there's no convenient way to rebuild a : > : single module for another architecture. I use the following script : > : called 'arch' to set the appropriate environment variables, so if : > : I've already run 'make universe' and I want to rebuild libc for : > : sparc64, I say: : > : : > : cd /usr/src/lib/libc && arch sparc64 make : > : : > : It would be nice if there were a better mechanism for this that's : > : integrated into the build system. : > : > I do one of the following: : > : > (1) env TARGET=arm make buildworld -DNO_CLEAN : > : > or : > : > (2) env TARGET=arm make buildenv : > $ cd lib/libc && make : > : > These both work out well enough in practice for me. I've wanted a : > target that was 'reworld' that just did an 'all' and maybe a few other : > things, but I've never had the time to polish this up (had it in a : > couple of trees that I lost due to disk failure). : > : > I do agree it would be nice if there was some way to do 'all' for a : > subdirectory with a 'trust me, I know what I'm doing, so don't do all : > that other stuff' flag. : > : > : I told das privately but will note publicly that: : : tools/tools/nanobsd/gateworks : : uses make buildenv to cross-build various bits. At some point I want to : promote some of the shell code to be part of nanobsd but until we've got : something to deal with ports I'm in no hurry. I've done similar things... Cross building ports is a very interesting problem... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 00:44:43 2009 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 3C662106564A; Mon, 12 Jan 2009 00:44:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D4D2E8FC16; Mon, 12 Jan 2009 00:44:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0C0h6pe052972; Sun, 11 Jan 2009 17:43:06 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 11 Jan 2009 17:43:27 -0700 (MST) Message-Id: <20090111.174327.-942991712.imp@bsdimp.com> To: das@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20090111191251.GA74450@zim.MIT.EDU> References: <20090111.095109.-1112748421.imp@bsdimp.com> <20090111172427.GD89178@hoeg.nl> <20090111191251.GA74450@zim.MIT.EDU> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ed@80386.nl, arch@FreeBSD.ORG Subject: Re: Quick hack to make fast kernel builds easier 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, 12 Jan 2009 00:44:43 -0000 In message: <20090111191251.GA74450@zim.MIT.EDU> David Schultz writes: : On Sun, Jan 11, 2009, Ed Schouten wrote: : > I often just run `make' in /usr/obj/..., : > which also saves some typing, but unfortunately that doesn't work when : > cross compiling. : : Also, as far as I know, there's no convenient way to rebuild a : single module for another architecture. I use the following script : called 'arch' to set the appropriate environment variables, so if : I've already run 'make universe' and I want to rebuild libc for : sparc64, I say: : : cd /usr/src/lib/libc && arch sparc64 make : : It would be nice if there were a better mechanism for this that's : integrated into the build system. : : #!/bin/sh : : arch=$1 : basepath=/usr/src : : export __MAKE_CONF=/dev/null : export MAKEOBJDIRPREFIX=/usr/obj/${arch} : export MACHINE_ARCH=${arch} : export MACHINE=${arch} : export CPUTYPE= : export GROFF_BIN_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin : export GROFF_FONT_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/groff_font : export GROFF_TMAC_PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/share/tmac : export _SHLIBDIRPREFIX=/usr/obj/${arch}${basepath}/tmp : export INSTALL="sh /usr/src/tools/install.sh" : export PATH=/usr/obj/${arch}${basepath}/tmp/legacy/usr/sbin:/usr/obj/${arch}${basepath}/tmp/legacy/usr/bin:/usr/obj/${arch}${basepath}/legacy/usr/games:/usr/obj/${arch}${basepath}/tmp/usr/sbin:/usr/obj/${arch}${basepath}/tmp/usr/bin:/usr/obj/${arch}${basepath}/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin : DESTDIR=/usr/obj/${arch}${basepath}/tmp : : shift : $* Also, the following is similar to what I've used in the past. I think it is a lot simpler and should be functionally equivalent. The key part is to have make tell you what env vars you need to export... #!/bin/sh # fxmake arch subdir make-target arch=$1 dir=$2 shift shift target=${*:-all} makevars=`env TARGET=$arch MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX:-/usr/obj} make buildenvvars` cd $2 && sh -c "${makevars}" make $target Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 05:44:35 2009 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 01820106566C for ; Mon, 12 Jan 2009 05:44:35 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id ABF1B8FC3A for ; Mon, 12 Jan 2009 05:44:34 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from [10.100.124.199] (port=49465 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMEwG-0006xS-4a; Mon, 12 Jan 2009 08:02:12 +0300 Date: Mon, 12 Jan 2009 08:02:06 +0300 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20090112050205.GA59401@edoofus.dev.vega.ru> References: <20090111.095109.-1112748421.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090111.095109.-1112748421.imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: Quick hack to make fast kernel builds easier 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, 12 Jan 2009 05:44:35 -0000 On Sun, Jan 11, 2009 at 09:51:09AM -0700, M. Warner Losh wrote: > This patch makes > > make buildkernel -DKERNFAST > > a short cut for > > make buildkernel -DNO_KERNELCLEAN -DNO_KERNELCONFIG -DNO_KERNELDEPEND > > which is a lot shorter to type. > > comments? > Except the "please don't use any values in assignments", I can't see a reason not to commit it if it's useful. > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 186807) > +++ Makefile.inc1 (working copy) > @@ -5,6 +5,7 @@ > # -DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir > # -DNO_CLEAN do not clean at all > # -DNO_SHARE do not go into share subdir > +# -DKERNFAST define NO_KERNELCONFIG, NO_KERNELCLEAN and NO_KERNELCONFIG > # -DNO_KERNELCONFIG do not run config in ${MAKE} buildkernel > # -DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} buildkernel > # -DNO_KERNELDEPEND do not run ${MAKE} depend in ${MAKE} buildkernel > @@ -697,6 +699,11 @@ > # be set to cross-build, we have to make sure TARGET is set > # properly. > > +.if defined(KERNFAST) > +NO_KERNELCLEAN= t > +NO_KERNELCONFIG= t > +NO_KERNELDEPEND= t > +.endif > .if !defined(KERNCONF) && defined(KERNEL) > KERNCONF= ${KERNEL} > KERNWARN= > -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 08:22:39 2009 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 393FC1065673; Mon, 12 Jan 2009 08:22:39 +0000 (UTC) (envelope-from prvs=julian=2560a13b2@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 1FDBB8FC16; Mon, 12 Jan 2009 08:22:39 +0000 (UTC) (envelope-from prvs=julian=2560a13b2@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.87]) by smtp-outbound.ironport.com with ESMTP; 11 Jan 2009 23:54:02 -0800 Message-ID: <496AF718.70005@elischer.org> Date: Sun, 11 Jan 2009 23:54:00 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Sam Leffler References: <20090111.095109.-1112748421.imp@bsdimp.com> <20090111172427.GD89178@hoeg.nl> <20090111191251.GA74450@zim.MIT.EDU> <20090111.142350.1560738814.imp@bsdimp.com> <496A65E1.5030309@freebsd.org> In-Reply-To: <496A65E1.5030309@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Quick hack to make fast kernel builds easier [really cross-build support] 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, 12 Jan 2009 08:22:39 -0000 Sam Leffler wrote: > M. Warner Losh wrote: >> In message: <20090111191251.GA74450@zim.MIT.EDU> >> David Schultz writes: >> : On Sun, Jan 11, 2009, Ed Schouten wrote: >> : > I often just run `make' in /usr/obj/..., >> : > which also saves some typing, but unfortunately that doesn't work >> when >> : > cross compiling. >> : : Also, as far as I know, there's no convenient way to rebuild a >> : single module for another architecture. I use the following script >> : called 'arch' to set the appropriate environment variables, so if >> : I've already run 'make universe' and I want to rebuild libc for >> : sparc64, I say: >> : : cd /usr/src/lib/libc && arch sparc64 make >> : : It would be nice if there were a better mechanism for this that's >> : integrated into the build system. >> >> I do one of the following: >> >> (1) env TARGET=arm make buildworld -DNO_CLEAN >> >> or >> >> (2) env TARGET=arm make buildenv >> $ cd lib/libc && make >> >> These both work out well enough in practice for me. I've wanted a >> target that was 'reworld' that just did an 'all' and maybe a few other >> things, but I've never had the time to polish this up (had it in a >> couple of trees that I lost due to disk failure). >> >> I do agree it would be nice if there was some way to do 'all' for a >> subdirectory with a 'trust me, I know what I'm doing, so don't do all >> that other stuff' flag. >> >> > I told das privately but will note publicly that: When Cisco was thinking of using BSD for the Nova project I had a cross build env set up for PPC. I had a chroot where all teh standard tools were cross tools... so 'cc' ran on a PC but gave PPC binaries. in addition all the libraries to link with etc. were all PPC libs. Seemed to work ok.. to rebuild tools WITHIN the chroo you did the build on the enclosing environment with a DESTDIR=/ppc-chroot TARTGET=PPC (or whatever it was) and to generate arbitrary PPC binaries you just compiled them normally within the chroot. > > tools/tools/nanobsd/gateworks > > uses make buildenv to cross-build various bits. At some point I want to > promote some of the shell code to be part of nanobsd but until we've got > something to deal with ports I'm in no hurry. > > Sam > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 10:19:36 2009 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 18807106566C for ; Mon, 12 Jan 2009 10:19:36 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id CC9C98FC39 for ; Mon, 12 Jan 2009 10:19:35 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1A6366D449; Mon, 12 Jan 2009 10:19:34 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id EBB9C844C6; Mon, 12 Jan 2009 11:19:33 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Luigi Rizzo References: <200812262231.mBQMVjHC052150@svn.freebsd.org> <867i59lvbj.fsf@ds4.des.no> <20090105142929.GA70683@onelab2.iet.unipi.it> <20090106121029.GA83861@onelab2.iet.unipi.it> Date: Mon, 12 Jan 2009 11:19:33 +0100 In-Reply-To: <20090106121029.GA83861@onelab2.iet.unipi.it> (Luigi Rizzo's message of "Tue, 6 Jan 2009 13:10:29 +0100") Message-ID: <86iqoksu6i.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Hartmut.Brandt@dlr.de Subject: Re: RFC: adding > and >= to /usr/bin/make conditionals ? 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, 12 Jan 2009 10:19:36 -0000 Luigi Rizzo writes: > So, I am polling to see if there is any consensus for or against > adding this feature to /usr/bin/make for also in favor of making comparisons in general more forgiving (removing constraints on the lhs etc.) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 11:06:49 2009 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 92CF510656C8 for ; Mon, 12 Jan 2009 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64DF48FC26 for ; Mon, 12 Jan 2009 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0CB6nK0091933 for ; Mon, 12 Jan 2009 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0CB6mNn091929 for freebsd-arch@FreeBSD.org; Mon, 12 Jan 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Jan 2009 11:06:48 GMT Message-Id: <200901121106.n0CB6mNn091929@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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, 12 Jan 2009 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 15:25:12 2009 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 1079C1065670 for ; Mon, 12 Jan 2009 15:25:12 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C7BDA8FC1B for ; Mon, 12 Jan 2009 15:25:11 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3CBB46D43F; Mon, 12 Jan 2009 15:06:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 15F53844ED; Mon, 12 Jan 2009 16:06:44 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net References: <4966B5D4.7040709@delphij.net> Date: Mon, 12 Jan 2009 16:06:44 +0100 In-Reply-To: <4966B5D4.7040709@delphij.net> (Xin LI's message of "Thu, 08 Jan 2009 18:26:28 -0800") Message-ID: <86zlhw5zsr.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@FreeBSD.org Subject: Re: RFC: MI strlen() 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, 12 Jan 2009 15:25:12 -0000 Xin LI writes: > Here is a new implementation of strlen() which employed the bitmask > skill in order to achieve better performance on modern hardware. Why bother? Do we have code that uses strlen() heavily in performance- critical regions? Does anybody? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 18:13:57 2009 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 56AF610656BB; Mon, 12 Jan 2009 18:13:57 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id B7E488FC21; Mon, 12 Jan 2009 18:13:56 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (HPooka@thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.3/8.14.3) with ESMTP id n0CHlfdO080740; Mon, 12 Jan 2009 11:47:41 -0600 (CST) (envelope-from scf@FreeBSD.org) Date: Mon, 12 Jan 2009 11:47:41 -0600 (CST) From: "Sean C. Farley" To: David Schultz In-Reply-To: <20090111191251.GA74450@zim.MIT.EDU> Message-ID: References: <20090111.095109.-1112748421.imp@bsdimp.com> <20090111172427.GD89178@hoeg.nl> <20090111191251.GA74450@zim.MIT.EDU> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: Ed Schouten , arch@FreeBSD.org Subject: Re: Quick hack to make fast kernel builds easier 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, 12 Jan 2009 18:13:57 -0000 On Sun, 11 Jan 2009, David Schultz wrote: > On Sun, Jan 11, 2009, Ed Schouten wrote: >> I often just run `make' in /usr/obj/..., >> which also saves some typing, but unfortunately that doesn't work >> when cross compiling. > > Also, as far as I know, there's no convenient way to rebuild a single > module for another architecture. I use the following script called > 'arch' to set the appropriate environment variables, so if I've > already run 'make universe' and I want to rebuild libc for sparc64, I > say: > > cd /usr/src/lib/libc && arch sparc64 make > > It would be nice if there were a better mechanism for this that's > integrated into the build system. *snip shell script* When I am building or installing a kernel and/or world, I use a shell script[1] I wrote awhile back. It could be better ("automatic" option probably does not work and should be removed), but it makes building and installing easier for me. I wonder how many build scripts have been written over the years. Sean 1. http://www.farley.org/freebsd/fbinst.sh -- scf@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Jan 13 06:54:03 2009 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 4B1C7106576E for ; Tue, 13 Jan 2009 06:54:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id E53168FC0A for ; Tue, 13 Jan 2009 06:54:02 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 305F828448 for ; Tue, 13 Jan 2009 14:54:02 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id BD0C4EC46D5; Tue, 13 Jan 2009 14:54:01 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id k5dS2PUE9T2d; Tue, 13 Jan 2009 14:53:56 +0800 (CST) Received: from charlie.delphij.net (c-67-188-86-134.hsd1.ca.comcast.net [67.188.86.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 60F98EC46C8; Tue, 13 Jan 2009 14:53:55 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Nn7dbsD/ZeyFcupANR2rkGAiCWGD5rw6bou1Oy64OusLG9fwMrP3E/Ku1zYPJJPXc GHiQsMC4E6xMAERwU9bqQ== Message-ID: <496C3A80.5040007@delphij.net> Date: Mon, 12 Jan 2009 22:53:52 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090112) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4966B5D4.7040709@delphij.net> <86zlhw5zsr.fsf@ds4.des.no> In-Reply-To: <86zlhw5zsr.fsf@ds4.des.no> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: d@delphij.net, freebsd-arch@FreeBSD.org Subject: Re: RFC: MI strlen() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 06:54:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dag-Erling Smørgrav wrote: > Xin LI writes: >> Here is a new implementation of strlen() which employed the bitmask >> skill in order to achieve better performance on modern hardware. > > Why bother? Do we have code that uses strlen() heavily in performance- > critical regions? Does anybody? I agree that strlen() should never be used in performance-sensitive regions, but given we do not have assembly optimized versions of these functions for amd64 and almost everybody else has it, having a C version that gives similar performance is valuable. Also, worldstone with -j9 on 2x4core machine with both src/ and obj/ in tmpfs, seems to have small, but positive effect: Unpatched libc: 1400.97 real 4159.34 user 2901.08 sys 1396.73 real 4159.06 user 2906.16 sys 1380.27 real 4158.20 user 2803.22 sys Patched libc: 1363.29 real 4154.89 user 2749.94 sys 1373.96 real 4150.45 user 2830.46 sys 1368.62 real 4152.48 user 2838.52 sys (with 'make cleanworld' between builds) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklsOoAACgkQi+vbBBjt66COQgCfTmpQK9YliCxpdJkckJ2/cZim NzEAoKRqC2HN1FtKRWaZhstYyVjYeewr =eeea -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 13 12:56:57 2009 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 818A51065672 for ; Tue, 13 Jan 2009 12:56:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B35A58FC16 for ; Tue, 13 Jan 2009 12:56:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA16135 for ; Tue, 13 Jan 2009 14:43:23 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <496C8C6A.2030708@icyb.net.ua> Date: Tue, 13 Jan 2009 14:43:22 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: smb(4): address format 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, 13 Jan 2009 12:56:57 -0000 Maybe this is not sufficiently suitable for arch@, but I couldn't think of a more relevant list. smb(4) conveniently omits specifying what SMBus slave address is. Ditto for iic(4). As you know the address itself is 7 bit but how to align those bits within a byte is somewhat ambiguous. Even the SMBus Specification sometimes refers to a 7-bit value as to a slave address, but sometimes uses phrases like "Slave Address Bits 7-1". The confusion seems to come from how the address is actually transmitted on the wire where the least significant bit of an address byte is used to indicate direction of an operation (read or write). So, in practice, there two conventions of specifying a slave address: either as 0XXXXXXXb or XXXXXXX0b. On FreeBSD we have a situation where smb/smbus doesn't insist on any convention nor try to enforce it, and specific hardware drivers have differing ideas. E.g. please see PR 100513: http://www.freebsd.org/cgi/query-pr.cgi?pr=100513 This inconsistency can not be a good thing. Maybe we should pick one format, document it and enforce it? >From FreeBSD-centric point of view XXXXXXX0b format seems to be preferable - IMHO, of course. Majority hardware drivers already expect this format, userland programs like mbmon and smbmsg(8) also seem to use it. In wider world 0XXXXXXXb format seems to be preferred, Linux also sticks to it. Of course, choosing one format means changes for those using the other one, but I think that having current inconsistency is worse. P.S. I hope this won't trigger a bikeshed discussion. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Tue Jan 13 14:08:51 2009 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 CAF641065670 for ; Tue, 13 Jan 2009 14:08:51 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 490338FC18 for ; Tue, 13 Jan 2009 14:08:51 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id n0DDqm9x056602; Tue, 13 Jan 2009 13:52:49 GMT (envelope-from rb@gid.co.uk) Received: from [192.168.255.1] (seagoon.gid.co.uk [194.32.164.1]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id n0DDqgwb057587; Tue, 13 Jan 2009 13:52:42 GMT (envelope-from rb@gid.co.uk) Message-Id: <284781C0-CC39-42C8-8772-83911A26FA85@gid.co.uk> From: Bob Bishop To: Andriy Gapon In-Reply-To: <496C8C6A.2030708@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 13 Jan 2009 13:52:42 +0000 References: <496C8C6A.2030708@icyb.net.ua> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-arch@freebsd.org Subject: Re: smb(4): address format 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, 13 Jan 2009 14:08:52 -0000 Hi, On 13 Jan 2009, at 12:43, Andriy Gapon wrote: > Maybe this is not sufficiently suitable for arch@, but I couldn't > think > of a more relevant list. > > smb(4) conveniently omits specifying what SMBus slave address is. > Ditto > for iic(4). > > As you know the address itself is 7 bit but how to align those bits > within a byte is somewhat ambiguous. Even the SMBus Specification > sometimes refers to a 7-bit value as to a slave address, but sometimes > uses phrases like "Slave Address Bits 7-1". The confusion seems to > come > from how the address is actually transmitted on the wire where the > least > significant bit of an address byte is used to indicate direction of an > operation (read or write). Version 2 of the standard is pretty clear that the MSb of the slave address is transmitted first and the LSb is the r/w indicator, but confusingly labels timing diagrams in bit transmission order so that slave address bit 7 is labelled 1 and the r/w bit is labelled 8. However it is clear from Fig 4-9 that the address bits precede the r/w bit on the wire. > So, in practice, there two conventions of specifying a slave address: > either as 0XXXXXXXb or XXXXXXX0b. While a convention is just that, it would seem to be perverse to put what is clearly the LSb at the left of the byte and I'd vote for XXXXXXX0b. > On FreeBSD we have a situation where smb/smbus doesn't insist on any > convention nor try to enforce it, and specific hardware drivers have > differing ideas. > > E.g. please see PR 100513: > http://www.freebsd.org/cgi/query-pr.cgi?pr=100513 > > This inconsistency can not be a good thing. > Maybe we should pick one format, document it and enforce it? > >> From FreeBSD-centric point of view XXXXXXX0b format seems to be > preferable - IMHO, of course. Majority hardware drivers already expect > this format, userland programs like mbmon and smbmsg(8) also seem to > use it. > > In wider world 0XXXXXXXb format seems to be preferred, Linux also > sticks > to it. > > Of course, choosing one format means changes for those using the other > one, but I think that having current inconsistency is worse. > > P.S. I hope this won't trigger a bikeshed discussion. Can you get a bikeshed with an SMBus interface? :-) > -- > Andriy Gapon -- Bob Bishop rb@gid.co.uk From owner-freebsd-arch@FreeBSD.ORG Tue Jan 13 14:12:11 2009 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 14BB51065675 for ; Tue, 13 Jan 2009 14:12:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 7636F8FC1D for ; Tue, 13 Jan 2009 14:12:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-107-120-227.carlnfd1.nsw.optusnet.com.au (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0DEBk9G018450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 01:11:47 +1100 Date: Wed, 14 Jan 2009 01:11:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Bruce Evans In-Reply-To: <20090113232658.E31712@delplex.bde.org> Message-ID: <20090114005432.Y31765@delplex.bde.org> References: <4966B5D4.7040709@delphij.net> <86zlhw5zsr.fsf@ds4.des.no> <496C3A80.5040007@delphij.net> <20090113232658.E31712@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: RFC: MI strlen() 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, 13 Jan 2009 14:12:13 -0000 On Wed, 14 Jan 2009, I wrote: > Also, it takes something like -fno-builtin-strlen in CFLAGS for the > libc strlen() to ever be used. On both amd64 and i386, gcc's builtin > strlen() uses an inline "rep scasb", which can be inferior to even the Actually, this is no longer true. gcc-4.2 on at least amd64 has the weird behaviour of disabling its "optimized" builtin strlen() with -O2 but not with -O1. Even spelling strlen as __builtin_strlen doesn't give the builtin. >> Unpatched libc: >> 1400.97 real 4159.34 user 2901.08 sys >> 1396.73 real 4159.06 user 2906.16 sys >> 1380.27 real 4158.20 user 2803.22 sys >> >> Patched libc: >> 1363.29 real 4154.89 user 2749.94 sys >> 1373.96 real 4150.45 user 2830.46 sys >> 1368.62 real 4152.48 user 2838.52 sys >> >> (with 'make cleanworld' between builds) > > I don't believe this improvement. First, it is far too large to have been > caused by changing libc strlen(). Second, libc strlen() is not normally > used. Since -O2 is a standard "optimization" for makeworld, libc strlen() is now normally used, at least on amd64 (i386 with certain -mcpu should be the same, but I guess it isn't). > My buildworld times on a 1x2core machine with nfs-mounted src/ and ffs > obj/ src are much smaller: > > 824.96 real 1294.35 user 187.09 sys > > but this is for FreeBSD-~5.2. FreeBSD and gcc have a combined bloat factor Of course I don't use -O2. > Here are some old files for too-simple strlen() benchmarks: > ... > I forget the results (don't have an amd64 machine handy for re-testing). I reran the test. I had to change -O2 to -O to test builtin strlen, and made some other changes in a failed attempt to force __builtin_strlen with -O2). builtin strlen is much slower than I remembered. The NetBSD asm strlen (it uses the 0x8080 trick with 64-bit words) is about 4.5 faster for long strings but slower for short strings (ones shorter than the word size). I expect your C version is similar. %%% string length 0: algorithm -DSTRLEN=__builtin_strlen: 0.35 real 0.35 user 0.00 sys algorithm -fno-builtin: 0.06 real 0.05 user 0.00 sys algorithm -fno-builtin zq.S: 0.09 real 0.09 user 0.00 sys string length 1: algorithm -DSTRLEN=__builtin_strlen: 0.39 real 0.38 user 0.00 sys algorithm -fno-builtin: 0.07 real 0.06 user 0.00 sys algorithm -fno-builtin zq.S: 0.13 real 0.12 user 0.00 sys string length 10: algorithm -DSTRLEN=__builtin_strlen: 0.68 real 0.66 user 0.01 sys algorithm -fno-builtin: 0.21 real 0.21 user 0.00 sys algorithm -fno-builtin zq.S: 0.12 real 0.10 user 0.00 sys string length 100: algorithm -DSTRLEN=__builtin_strlen: 3.60 real 3.60 user 0.00 sys algorithm -fno-builtin: 1.02 real 1.01 user 0.00 sys algorithm -fno-builtin zq.S: 0.26 real 0.26 user 0.00 sys string length 1000: algorithm -DSTRLEN=__builtin_strlen: 32.79 real 32.78 user 0.00 sys algorithm -fno-builtin: 7.25 real 7.25 user 0.00 sys algorithm -fno-builtin zq.S: 1.55 real 1.54 user 0.00 sys %%% %%% #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'z.c' <<'END_OF_FILE' X#include X#include X#include X X#ifndef LEN X#define LEN 5 X#endif X X#ifndef STRLEN X#define STRLEN strlen X#endif X Xstatic char *foo[1000]; Xstatic volatile size_t s; X X#ifdef MISTRLEN X#include "/usr/src/lib/libc/string/strlen.c" X#endif X Xint Xmain(void) X{ X int i; X X for (i = 0; i < 10; i++) { X foo[i] = malloc(LEN + 1); X sprintf(foo[i], "%*.*s", LEN, LEN, "foo"); X } X for (i = 0; i < 10000000; i++) X s = STRLEN(foo[i % 10]); X return (0); X} END_OF_FILE if test 463 -ne `wc -c <'z.c'`; then echo shar: \"'z.c'\" unpacked with wrong size! fi # end of 'z.c' fi if test -f 'zi' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'zi'\" else echo shar: Extracting \"'zi'\" \(224 characters\) sed "s/^X//" >'zi' <<'END_OF_FILE' Xfor len in 0 1 10 100 1000 Xdo X echo "string length $len:" X for alg in -DSTRLEN=__builtin_strlen -fno-builtin "-fno-builtin zq.S" X do X echo "algorithm $alg:" X cc -o z z.c -O $alg -g -static -DLEN=$len X time ./z X done Xdone END_OF_FILE if test 224 -ne `wc -c <'zi'`; then echo shar: \"'zi'\" unpacked with wrong size! fi # end of 'zi' fi if test -f 'zq.S' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'zq.S'\" else echo shar: Extracting \"'zq.S'\" \(4304 characters\) sed "s/^X//" >'zq.S' <<'END_OF_FILE' X/* X * Written by J.T. Conklin X * Public domain. X */ X X#include X__FBSDID("$FreeBSD$"); X X#if 0 X RCSID("$NetBSD: strlen.S,v 1.3 2004/07/19 20:04:41 drochner Exp $") X#endif X XENTRY(strlen) X movq %rdi,%rax X negq %rdi X X.Lalign: X /* Consider unrolling loop? */ X testb $7,%al X je .Lword_aligned X cmpb $0,(%rax) X jne 1f X leaq (%rdi,%rax),%rax X ret X1: incq %rax X jmp .Lalign X X /* X * There are many well known branch-free sequences which are used X * for determining whether a zero-byte is contained within a word. X * These sequences are generally much more efficent than loading X * and comparing each byte individually. X * X * The expression [1,2]: X * X * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) X * X * evaluates to a non-zero value if any of the bytes in the X * original word is zero. X * X * It also has the useful property that bytes in the result word X * that coorespond to non-zero bytes in the original word have X * the value 0x00, while bytes cooresponding to zero bytes have X * the value 0x80. This allows calculation of the first (and X * last) occurance of a zero byte within the word (useful for C's X * str* primitives) by counting the number of leading (or X * trailing) zeros and dividing the result by 8. On machines X * without (or with slow) clz() / ctz() instructions, testing X * each byte in the result word for zero is necessary. X * X * This typically takes 4 instructions (5 on machines without X * "not-or") not including those needed to load the constant. X * X * X * The expression: X * X * (2) ((x - 0x01....01) & ~x & 0x80....80) X * X * evaluates to a non-zero value if any of the bytes in the X * original word is zero. X * X * On little endian machines, the first byte in the result word X * that cooresponds to a zero byte in the original byte is 0x80, X * so clz() can be used as above. On big endian machines, and X * little endian machines without (or with a slow) clz() insn, X * testing each byte in the original for zero is necessary X * X * This typically takes 3 instructions (4 on machines without X * "and with complement") not including those needed to load X * constants. X * X * X * The expression: X * X * (3) ((x - 0x01....01) & 0x80....80) X * X * always evaluates to a non-zero value if any of the bytes in X * the original word is zero. However, in rare cases, it also X * evaluates to a non-zero value when none of the bytes in the X * original word is zero. X * X * To account for possible false positives, each byte of the X * original word must be checked when the expression evaluates to X * a non-zero value. However, because it is simpler than those X * presented above, code that uses it will be faster as long as X * the rate of false positives is low. X * X * This is likely, because the the false positive can only occur X * if the most siginificant bit of a byte within the word is set. X * The expression will never fail for typical 7-bit ASCII strings. X * X * This typically takes 2 instructions not including those needed X * to load constants. X * X * X * [1] Henry S. Warren Jr., "Hacker's Delight", Addison-Westley 2003 X * X * [2] International Business Machines, "The PowerPC Compiler Writer's X * Guide", Warthman Associates, 1996 X */ X X .align 4 X.Lword_aligned: X movabsq $0x0101010101010101,%r8 X movabsq $0x8080808080808080,%r9 X.Lloop: X movq (%rax),%rdx X addq $8,%rax X subq %r8,%rdx X testq %r9,%rdx X je .Lloop X X /* X * In rare cases, the above loop may exit prematurely. We must X * return to the loop if none of the bytes in the word equal 0. X */ X cmpb $0,-8(%rax) /* 1st byte == 0? */ X je .Lsub8 X cmpb $0,-7(%rax) /* 2nd byte == 0? */ X je .Lsub7 X cmpb $0,-6(%rax) /* 3rd byte == 0? */ X je .Lsub6 X cmpb $0,-5(%rax) /* 4th byte == 0? */ X je .Lsub5 X cmpb $0,-4(%rax) /* 5th byte == 0? */ X je .Lsub4 X cmpb $0,-3(%rax) /* 6th byte == 0? */ X je .Lsub3 X cmpb $0,-2(%rax) /* 7th byte == 0? */ X je .Lsub2 X cmpb $0,-1(%rax) /* 8th byte == 0? */ X jne .Lloop X X.Lsub1: X leaq -1(%rdi,%rax),%rax X ret X.Lsub2: X leaq -2(%rdi,%rax),%rax X ret X.Lsub3: X leaq -3(%rdi,%rax),%rax X ret X.Lsub4: X leaq -4(%rdi,%rax),%rax X ret X.Lsub5: X leaq -5(%rdi,%rax),%rax X ret X.Lsub6: X leaq -6(%rdi,%rax),%rax X ret X.Lsub7: X leaq -7(%rdi,%rax),%rax X ret X.Lsub8: X leaq -8(%rdi,%rax),%rax X ret END_OF_FILE if test 4304 -ne `wc -c <'zq.S'`; then echo shar: \"'zq.S'\" unpacked with wrong size! fi # end of 'zq.S' fi echo shar: End of shell archive. exit 0 %%% Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Jan 13 16:18:49 2009 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 6C3FE106564A for ; Tue, 13 Jan 2009 16:18:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6F48FC1F for ; Tue, 13 Jan 2009 16:18:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0DDYGMc029620 for ; Wed, 14 Jan 2009 00:34:16 +1100 Received: from c122-107-120-227.carlnfd1.nsw.optusnet.com.au (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0DDXVMu027751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 00:33:33 +1100 Date: Wed, 14 Jan 2009 00:33:31 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: d@delphij.net In-Reply-To: <496C3A80.5040007@delphij.net> Message-ID: <20090113232658.E31712@delplex.bde.org> References: <4966B5D4.7040709@delphij.net> <86zlhw5zsr.fsf@ds4.des.no> <496C3A80.5040007@delphij.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-471949903-1231853611=:31712" Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , freebsd-arch@freebsd.org Subject: Re: RFC: MI strlen() 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, 13 Jan 2009 16:18:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-471949903-1231853611=:31712 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 12 Jan 2009, Xin LI wrote: > Dag-Erling Sm=C3=B8rgrav wrote: >> Xin LI writes: >>> Here is a new implementation of strlen() which employed the bitmask >>> skill in order to achieve better performance on modern hardware. >> >> Why bother? Do we have code that uses strlen() heavily in performance- >> critical regions? Does anybody? Of course not. Also, it takes something like -fno-builtin-strlen in CFLAGS for the libc strlen() to ever be used. On both amd64 and i386, gcc's builtin strlen() uses an inline "rep scasb", which can be inferior to even the simple C loop in the simple libc version since i386ish string instructions tend to be inferior (e.g., on AthlonXP, "rep scas*" takes 2.5 cycles per iteration, plus 15 cycles to start, possibly plus extra startup/finishu= p costs to use specific registers for it, while the simple C loop takes 1 cycle per iteration and can have startup costs much smaller than 15+ cycles (but the function call for the libc version costs about 15 cycles). I think most strings are short, so sophisticated methods will usually lose since they take longer to start up and have more branches. However, the loss is usually unnoticable since it doesn't take long to process a non-huge number of short strings. The "optimized" asm i386 strlen() also uses "rep scasb", so it tends to be inferior to the simple C version. The "optimized" asm amd64 strlen() intentionally doesn't exist, since the "rep scasb" version of it is believed to be slower than the simple C version on all amd64 CPUs, and more sophisticated versions would take more work to implement and might end up being no better, and anyway the gcc builtin normally provides the "rep scasb" "optimization, so even more work would be required to actually usually use the sophisticated versions. amd64 still has "optimized" asm versions of strcat(), strcmp() and strcpy(), and actually-optimized asm version of the memcpy() family. For memcpy(), the string instruction actually tends to be faster (1.33 cycles/iteration on AthlonXP, same on A64 IIRC, and faster on Phenom IIRC), though it still wins mainly because it does 64 bits at a time while the simple libc version only does 32 bits at a time (due to its rotted code: typedef int word;=09=09/* "word" used for optimal copy speed */ -- 32-bit words are of course far from optimal on 64-bit machines). Another issue for the memcpy() family is gcc doesn't have a builtin for everything. IIRC, it doesn't have one for memcpy() since handling overlapping copies makes the inline version too large. > I agree that strlen() should never be used in performance-sensitive > regions, but given we do not have assembly optimized versions of these > functions for amd64 and almost everybody else has it, having a C version > that gives similar performance is valuable. Also, worldstone with -j9 > on 2x4core machine with both src/ and obj/ in tmpfs, seems to have > small, but positive effect: > > Unpatched libc: > 1400.97 real 4159.34 user 2901.08 sys > 1396.73 real 4159.06 user 2906.16 sys > 1380.27 real 4158.20 user 2803.22 sys > > Patched libc: > 1363.29 real 4154.89 user 2749.94 sys > 1373.96 real 4150.45 user 2830.46 sys > 1368.62 real 4152.48 user 2838.52 sys > > (with 'make cleanworld' between builds) I don't believe this improvement. First, it is far too large to have been caused by changing libc strlen(). Second, libc strlen() is not normally used. My buildworld times on a 1x2core machine with nfs-mounted src/ and ffs obj/ src are much smaller: 824.96 real 1294.35 user 187.09 sys but this is for FreeBSD-~5.2. FreeBSD and gcc have a combined bloat factor of almost 4 since then :-(, and more cores don't help much, apparently due to them always running into locks (the bloat factor for system time is almost 15, and that is with nfs bloating my sys time by about a factor of 2). Here are some old files for too-simple strlen() benchmarks: %%% #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'z' <<'END_OF_FILE' END_OF_FILE if test 0 -ne `wc -c <'z'`; then echo shar: \"'z'\" unpacked with wrong size! fi # end of 'z' fi if test -f 'z.c' -a "${1}" !=3D "-c" ; then echo shar: Will not clobber existing file \"'z.c'\" else echo shar: Extracting \"'z.c'\" \(418 characters\) sed "s/^X//" >'z.c' <<'END_OF_FILE' X#include X#include X#include X X#ifndef LEN X#define=09LEN=095 X#endif X Xstatic char *foo[1000]; Xstatic volatile size_t s; X X#ifdef MISTRLEN X#include "/usr/src/lib/libc/string/strlen.c" X#endif X Xint Xmain(void) X{ X=09int i; X X=09for (i =3D 0; i < 10; i++) { X=09=09foo[i] =3D malloc(LEN + 1); X=09=09sprintf(foo[i], "%*.*s", LEN, LEN, "foo"); X=09} X=09for (i =3D 0; i < 10000000; i++) X=09=09s =3D strlen(foo[i % 10]); X=09return (0); X} END_OF_FILE if test 418 -ne `wc -c <'z.c'`; then echo shar: \"'z.c'\" unpacked with wrong size! fi # end of 'z.c' fi if test -f 'zi' -a "${1}" !=3D "-c" ; then echo shar: Will not clobber existing file \"'zi'\" else echo shar: Extracting \"'zi'\" \(209 characters\) sed "s/^X//" >'zi' <<'END_OF_FILE' Xfor len in 0 1 10 100 1000 Xdo X=09echo "string length $len:" X=09for alg in -fbuiltin -fno-builtin "-fno-builtin zq.S" X=09do X=09=09echo "algorithm $alg:" X=09=09cc -o z z.c -O2 $alg -g -static -DLEN=3D$len X=09=09time ./z X=09done Xdone END_OF_FILE if test 209 -ne `wc -c <'zi'`; then echo shar: \"'zi'\" unpacked with wrong size! fi # end of 'zi' fi if test -f 'zq.S' -a "${1}" !=3D "-c" ; then echo shar: Will not clobber existing file \"'zq.S'\" else echo shar: Extracting \"'zq.S'\" \(4304 characters\) sed "s/^X//" >'zq.S' <<'END_OF_FILE' X/* X * Written by J.T. Conklin X * Public domain. X */ X X#include X__FBSDID("$FreeBSD$"); X X#if 0 X=09RCSID("$NetBSD: strlen.S,v 1.3 2004/07/19 20:04:41 drochner Exp $") X#endif X XENTRY(strlen) X=09movq=09%rdi,%rax X=09negq=09%rdi X X.Lalign: X=09/* Consider unrolling loop? */ X=09testb=09$7,%al X=09je=09.Lword_aligned X=09cmpb=09$0,(%rax) X=09jne=091f X=09leaq=09(%rdi,%rax),%rax X=09ret X1:=09incq=09%rax X=09jmp=09.Lalign X X=09/* X=09 * There are many well known branch-free sequences which are used X=09 * for determining whether a zero-byte is contained within a word. X=09 * These sequences are generally much more efficent than loading X=09 * and comparing each byte individually. X=09 * X=09 * The expression [1,2]: X=09 * X=09 * (1) ~(((x & 0x7f....7f) + 0x7f....7f) | (x | 0x7f....7f)) X=09 * X=09 * evaluates to a non-zero value if any of the bytes in the X=09 * original word is zero. X=09 * X=09 * It also has the useful property that bytes in the result word X=09 * that coorespond to non-zero bytes in the original word have X=09 * the value 0x00, while bytes cooresponding to zero bytes have X=09 * the value 0x80. This allows calculation of the first (and X=09 * last) occurance of a zero byte within the word (useful for C's X=09 * str* primitives) by counting the number of leading (or X=09 * trailing) zeros and dividing the result by 8. On machines X=09 * without (or with slow) clz() / ctz() instructions, testing X=09 * each byte in the result word for zero is necessary. X=09 * X=09 * This typically takes 4 instructions (5 on machines without X=09 * "not-or") not including those needed to load the constant. X=09 * X=09 * X=09 * The expression: X=09 * X=09 * (2) ((x - 0x01....01) & ~x & 0x80....80) X=09 * X=09 * evaluates to a non-zero value if any of the bytes in the X=09 * original word is zero. X=09 * X=09 * On little endian machines, the first byte in the result word X=09 * that cooresponds to a zero byte in the original byte is 0x80, X=09 * so clz() can be used as above. On big endian machines, and X=09 * little endian machines without (or with a slow) clz() insn, X=09 * testing each byte in the original for zero is necessary X=09 * X=09 * This typically takes 3 instructions (4 on machines without X=09 * "and with complement") not including those needed to load X=09 * constants. X=09 * X=09 * X=09 * The expression: X=09 * X=09 * (3) ((x - 0x01....01) & 0x80....80) X=09 * X=09 * always evaluates to a non-zero value if any of the bytes in X=09 * the original word is zero. However, in rare cases, it also X=09 * evaluates to a non-zero value when none of the bytes in the X=09 * original word is zero. X=09 * X=09 * To account for possible false positives, each byte of the X=09 * original word must be checked when the expression evaluates to X=09 * a non-zero value. However, because it is simpler than those X=09 * presented above, code that uses it will be faster as long as X=09 * the rate of false positives is low. X=09 * X=09 * This is likely, because the the false positive can only occur X=09 * if the most siginificant bit of a byte within the word is set. X=09 * The expression will never fail for typical 7-bit ASCII strings. X=09 * X=09 * This typically takes 2 instructions not including those needed X=09 * to load constants. X=09 * X=09 * X=09 * [1] Henry S. Warren Jr., "Hacker's Delight", Addison-Westley 2003 X=09 * X=09 * [2] International Business Machines, "The PowerPC Compiler Writer's X=09 * Guide", Warthman Associates, 1996 X=09 */ X X=09.align 4 X.Lword_aligned: X=09movabsq=09$0x0101010101010101,%r8 X=09movabsq=09$0x8080808080808080,%r9 X.Lloop: X=09movq=09(%rax),%rdx X=09addq=09$8,%rax X=09subq=09%r8,%rdx X=09testq=09%r9,%rdx X=09je=09.Lloop X X=09/* X=09 * In rare cases, the above loop may exit prematurely. We must X=09 * return to the loop if none of the bytes in the word equal 0. X=09 */ X=09cmpb=09$0,-8(%rax)=09=09/* 1st byte =3D=3D 0? */ X=09je=09.Lsub8 X=09cmpb=09$0,-7(%rax)=09=09/* 2nd byte =3D=3D 0? */ X=09je=09.Lsub7 X=09cmpb=09$0,-6(%rax)=09=09/* 3rd byte =3D=3D 0? */ X=09je=09.Lsub6 X=09cmpb=09$0,-5(%rax)=09=09/* 4th byte =3D=3D 0? */ X=09je=09.Lsub5 X=09cmpb=09$0,-4(%rax)=09=09/* 5th byte =3D=3D 0? */ X=09je=09.Lsub4 X=09cmpb=09$0,-3(%rax)=09=09/* 6th byte =3D=3D 0? */ X=09je=09.Lsub3 X=09cmpb=09$0,-2(%rax)=09=09/* 7th byte =3D=3D 0? */ X=09je=09.Lsub2 X=09cmpb=09$0,-1(%rax)=09=09/* 8th byte =3D=3D 0? */ X=09jne=09.Lloop X X.Lsub1: X=09leaq=09-1(%rdi,%rax),%rax X=09ret X.Lsub2: X=09leaq=09-2(%rdi,%rax),%rax X=09ret X.Lsub3: X=09leaq=09-3(%rdi,%rax),%rax X=09ret X.Lsub4: X=09leaq=09-4(%rdi,%rax),%rax X=09ret X.Lsub5: X=09leaq=09-5(%rdi,%rax),%rax X=09ret X.Lsub6: X=09leaq=09-6(%rdi,%rax),%rax X=09ret X.Lsub7: X=09leaq=09-7(%rdi,%rax),%rax X=09ret X.Lsub8: X=09leaq=09-8(%rdi,%rax),%rax X=09ret END_OF_FILE if test 4304 -ne `wc -c <'zq.S'`; then echo shar: \"'zq.S'\" unpacked with wrong size! fi # end of 'zq.S' fi echo shar: End of shell archive. exit 0 %%% Here - z.c is a simple C program that calls strlen() - zi is a shell script that tries various algrithms (sorry, no makefile) - zq.S is the NetBSD amd64 asm version which uses the 0x8080 trick and not "rep scasb" The algorithms are: - -fbuiltin: try to use builtin strlen() - -fno-builtin: use default libc strlen(), except if MISTRLEN is defined, use MI libc strlen(). Variation to use MISTRLEN is not supported by zi. - -fno-builtin zq.S: use NetBSD amd64 strlen() I forget the results (don't have an amd64 machine handy for re-testing). Bruce --0-471949903-1231853611=:31712-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 13 18:31:50 2009 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 35A921065675 for ; Tue, 13 Jan 2009 18:31:50 +0000 (UTC) (envelope-from prvs=julian=257c50d56@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF3F8FC1E for ; Tue, 13 Jan 2009 18:31:50 +0000 (UTC) (envelope-from prvs=julian=257c50d56@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.222]) by smtp-outbound.ironport.com with ESMTP; 13 Jan 2009 10:03:15 -0800 Message-ID: <496CD763.80107@elischer.org> Date: Tue, 13 Jan 2009 10:03:15 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Bruce Evans References: <4966B5D4.7040709@delphij.net> <86zlhw5zsr.fsf@ds4.des.no> <496C3A80.5040007@delphij.net> <20090113232658.E31712@delplex.bde.org> <20090114005432.Y31765@delplex.bde.org> In-Reply-To: <20090114005432.Y31765@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: RFC: MI strlen() 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, 13 Jan 2009 18:31:50 -0000 > > I reran the test. I had to change -O2 to -O to test builtin strlen, > and made some other changes in a failed attempt to force __builtin_strlen > with -O2). builtin strlen is much slower than I remembered. The > NetBSD asm strlen (it uses the 0x8080 trick with 64-bit words) is > about 4.5 faster for long strings but slower for short strings (ones > shorter than the word size). I expect your C version is similar. any chance you could try this and make a suggestion as to whether we might adopt the new code? > From owner-freebsd-arch@FreeBSD.ORG Wed Jan 14 07:43:08 2009 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 7CA29106564A for ; Wed, 14 Jan 2009 07:43:08 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 16E3F8FC13 for ; Wed, 14 Jan 2009 07:43:07 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n0E7HpCq086803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2009 08:17:51 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Andriy Gapon In-Reply-To: <496C8C6A.2030708@icyb.net.ua> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 14 Jan 2009 08:17:50 +0100 References: <496C8C6A.2030708@icyb.net.ua> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-arch@freebsd.org Subject: Re: smb(4): address format 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, 14 Jan 2009 07:43:09 -0000 Am 13.01.2009 um 13:43 schrieb Andriy Gapon: > So, in practice, there two conventions of specifying a slave address: > either as 0XXXXXXXb or XXXXXXX0b. Device datasheets generally specify the hard-wired or configurable =20 address as a bit string, with a slight preference to format that as =20 bbbb bbb. > In wider world 0XXXXXXXb format seems to be preferred, Linux also =20 > sticks > to it. I personally find having the address right-aligned a sensible choice. =20= I think of the address as logical unit, and normally would rather have =20= the SMBus bit banging abstracted away by the driver/hardware. =80 0.02, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 14 15:18:06 2009 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 BCF121065670; Wed, 14 Jan 2009 15:18:06 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc3-s4.col0.hotmail.com (col0-omc3-s4.col0.hotmail.com [65.55.34.142]) by mx1.freebsd.org (Postfix) with ESMTP id 9F23F8FC2C; Wed, 14 Jan 2009 15:18:06 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W14 ([65.55.34.136]) by col0-omc3-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 07:06:07 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: , , Date: Wed, 14 Jan 2009 15:06:06 +0000 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jan 2009 15:06:07.0001 (UTC) FILETIME=[A0480090:01C97659] Cc: Subject: Cross compiling FreeBSD 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, 14 Jan 2009 15:18:07 -0000 > From: andrew.hotlab@hotmail.com > To: freebsd-questions@freebsd.org > Subject: Builder for many architectures and releases > Date: Sat=2C 10 Jan 2009 02:37:37 +0000 > > [...] I looked for any documentation about setup a FreeBSD builder machin= e which will track sources and build binaries for all the hardware platform= and OS releases I need to support in my network. I have found some interes= ting articles (http://www.onlamp.com/pub/a/bsd/2006/04/13/freebsd-build-sys= tem.html - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-= lan.html)=2C but nothing which actually addresses my needs. [...] > At this time=2C I've tried to build RELENG_7_1 for the i386 architecture us= ing an amd64 machine (running RELENG_7_0 for amd64) then=2C exporting /usr/= src and /usr/obj via NFS in read-only mode to target machines=2C I've exper= ienced a lot of troubles trying to install both kernel and world=2C which m= ade impossible for me to install FreeBSD on target i386 machines. Can anyone kindly confirm that it's a supported procedure to compile FreeBS= D for a Tier1 architecture by using another Tier1-architecture machine? May= be I didn't understood documentation or I'm missing some essential steps in= the build process? Andrew P.S.: sorry for this cross-posting=2C but I don't have a clear understand a= bout what list best suits my question! _________________________________________________________________ Show them the way! Add maps and directions to your party invites.=20 http://www.microsoft.com/windows/windowslive/events.aspx= From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 00:36:58 2009 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 63E251065670 for ; Thu, 15 Jan 2009 00:36:58 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id A40AD8FC13 for ; Thu, 15 Jan 2009 00:36:56 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0ELGTZA011265 for ; Thu, 15 Jan 2009 08:16:29 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0ELGKat023034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 08:16:21 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n0ELGHEO030025; Thu, 15 Jan 2009 08:16:17 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n0ELGHSl030024; Thu, 15 Jan 2009 08:16:17 +1100 (EST) (envelope-from peter) Date: Thu, 15 Jan 2009 08:16:17 +1100 From: Peter Jeremy To: Andrew Hotlab Message-ID: <20090114211616.GC16116@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-i386@amd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD 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, 15 Jan 2009 00:36:58 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Please wrap your lines before 80 columns] On 2009-Jan-14 15:06:06 +0000, Andrew Hotlab wr= ote: >At this time, I've tried to build RELENG_7_1 for the i386 >architecture using an amd64 machine (running RELENG_7_0 for amd64) >then, exporting /usr/src and /usr/obj via NFS in read-only mode to >target machines, This won't work because install{world,kernel} uses programs (under /usr/obj) that were built to run on the build system (amd64 in your case) and so won't run on the target (i386) system. The supported approach is to NFS mount the target machines onto the build machine and run "make DESTDIR=3D/mount/point install{world,kernel}" on the build machine. Note that this will report errors since NFS cannot handle UFS flags - you will need to manually remove/add schg flags. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkluViAACgkQ/opHv/APuIe7uwCfY9BGyzbQAIqQBF5FRGFDHGjO /4UAoJaUBdgVy0eyN1PhLww9kzTEJkK5 =MgHu -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 01:14:18 2009 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 DD7E01065672; Thu, 15 Jan 2009 01:14:18 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc3-s9.col0.hotmail.com (col0-omc3-s9.col0.hotmail.com [65.55.34.147]) by mx1.freebsd.org (Postfix) with ESMTP id BA27B8FC16; Thu, 15 Jan 2009 01:14:18 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W21 ([65.55.34.136]) by col0-omc3-s9.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 17:12:04 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Thu, 15 Jan 2009 01:12:03 +0000 Importance: Normal In-Reply-To: <20090114211616.GC16116@server.vk2pj.dyndns.org> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jan 2009 01:12:04.0117 (UTC) FILETIME=[46CFA450:01C976AE] Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD 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, 15 Jan 2009 01:14:19 -0000 > > [Please wrap your lines before 80 columns] > I'm so sorry for that: I'm using the Windows Live webmail=2C and it seems impossible to have a decent message format! :( > On 2009-Jan-14 15:06:06 +0000=2C Andrew Hotlab wrote: >>At this time=2C I've tried to build RELENG_7_1 for the i386 >>architecture using an amd64 machine (running RELENG_7_0 for amd64) >>then=2C exporting /usr/src and /usr/obj via NFS in read-only mode to >>target machines=2C > > This won't work because install{world=2Ckernel} uses programs (under > /usr/obj) that were built to run on the build system (amd64 in > your case) and so won't run on the target (i386) system. > So I actually misunderstood the Handbook: only now I realize that it gives the suggestion to export /usr/obj and /usr/src from the build machine= =2C but only if the target architecture is the same as the builder! :S > The supported approach is to NFS mount the target machines onto the > build machine and run "make DESTDIR=3D/mount/point install{world=2Ckernel= }" > on the build machine. Note that this will report errors since NFS > cannot handle UFS flags - you will need to manually remove/add schg flags= . > Ok=2C so I think that in a production environment I should deploy one build= er machine for each target architecture I have to support on my network... I'm right? One last question: I would expect the same issues if I wish to to support m= any FreeBSD releases running of one single type of architecture? (i.e.: both bu= ilder and targets are amd64 machines=2C but I run RELENG_7 on the builder and RELENG_6_4 and RELENG_7_1 on the targets) Thanks for your explanation. _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Space= s. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.= aspx&mkt=3Den-us= From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 05:07:36 2009 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 76BCA1065677; Thu, 15 Jan 2009 05:07:36 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 971B18FC18; Thu, 15 Jan 2009 05:07:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n0F4hARG072641; Wed, 14 Jan 2009 22:43:10 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n0F4h9dk072640; Wed, 14 Jan 2009 22:43:09 -0600 (CST) (envelope-from brooks) Date: Wed, 14 Jan 2009 22:43:09 -0600 From: Brooks Davis To: Andrew Reilly Message-ID: <20090115044309.GA72611@lor.one-eyed-alien.net> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> <20090115031847.GA52343@duncan.reilly.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <20090115031847.GA52343@duncan.reilly.home> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 14 Jan 2009 22:43:10 -0600 (CST) Cc: freebsd-arch@freebsd.org, freebsd-i386@amd.org, freebsd-amd64@freebsd.org, Andrew Hotlab Subject: Re: Cross compiling FreeBSD 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, 15 Jan 2009 05:07:37 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2009 at 02:18:47PM +1100, Andrew Reilly wrote: > On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote: > > This won't work because install{world,kernel} uses programs (under > > /usr/obj) that were built to run on the build system (amd64 in > > your case) and so won't run on the target (i386) system. > >=20 > > The supported approach is to NFS mount the target machines onto the > > build machine and run "make DESTDIR=3D/mount/point install{world,kernel= }" > > on the build machine. Note that this will report errors since NFS > > cannot handle UFS flags - you will need to manually remove/add schg fla= gs. >=20 > Is there any reason (apart from using more space on the build > machine) not to install to a DESTDIR (not /) on the build > machine, and then tar/pax/cpio that tree across to the client > system? Presumably something like that must be done for the > distribution builds that go into making the CD and DVD images. This should work just fine. I use installs to DESTDIR to build images to be run at NFS root file systems. > NetBSD has (had? it's been a while since I looked) a cool > mechanism that allowed the whole tree to be built (and > "installed" to a DESTDIR) without root permissions, using a > variation on install that copied the file as the running user > and recorded the intended user/group/mod/flags in an mtree file. > Then a subsequent task created a tarball that contained the file > contents and the mtree permissions, all as a non-root user. So > you don't even need to muck about with root-over-nfs issues for > deployment: just log into the client and untar the distribution > over the network (as root). Very, very neat, IMO. I used to > build embedded i386 NetBSD installations on my amd64 FreeBSD > system that way without much in the way of trouble. Haven't had > to do it for a while, though, so perhaps it's all changed. I > wouldn't hate to discover that FreeBSD can do that too, > though... We don't have this yet, but lots of people would like to see this (just not quite enough to do it yet :). -- Brooks --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJbr7dXY6L6fI4GtQRAgqSAJwPebbKBrXyApQ+0U7Vudbqh29iWwCeIg9H URW9B8dwCno/i5JjU8YaY2o= =OwxX -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 05:45:05 2009 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 44649106566B for ; Thu, 15 Jan 2009 05:45:05 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id AC0948FC17 for ; Thu, 15 Jan 2009 05:45:04 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n0F5HB06025844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 21:17:11 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <496EC6D7.4090003@freebsd.org> Date: Wed, 14 Jan 2009 21:17:11 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Brooks Davis References: <20090114211616.GC16116@server.vk2pj.dyndns.org> <20090115031847.GA52343@duncan.reilly.home> <20090115044309.GA72611@lor.one-eyed-alien.net> In-Reply-To: <20090115044309.GA72611@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: Andrew Hotlab , freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD 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, 15 Jan 2009 05:45:05 -0000 Brooks Davis wrote: > On Thu, Jan 15, 2009 at 02:18:47PM +1100, Andrew Reilly wrote: >> On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote: >>> This won't work because install{world,kernel} uses programs (under >>> /usr/obj) that were built to run on the build system (amd64 in >>> your case) and so won't run on the target (i386) system. >>> >>> The supported approach is to NFS mount the target machines onto the >>> build machine and run "make DESTDIR=/mount/point install{world,kernel}" >>> on the build machine. Note that this will report errors since NFS >>> cannot handle UFS flags - you will need to manually remove/add schg flags. >> Is there any reason (apart from using more space on the build >> machine) not to install to a DESTDIR (not /) on the build >> machine, and then tar/pax/cpio that tree across to the client >> system? Presumably something like that must be done for the >> distribution builds that go into making the CD and DVD images. > > This should work just fine. I use installs to DESTDIR to build images to be > run at NFS root file systems. +1 > >> NetBSD has (had? it's been a while since I looked) a cool >> mechanism that allowed the whole tree to be built (and >> "installed" to a DESTDIR) without root permissions, using a >> variation on install that copied the file as the running user >> and recorded the intended user/group/mod/flags in an mtree file. >> Then a subsequent task created a tarball that contained the file >> contents and the mtree permissions, all as a non-root user. So >> you don't even need to muck about with root-over-nfs issues for >> deployment: just log into the client and untar the distribution >> over the network (as root). Very, very neat, IMO. I used to >> build embedded i386 NetBSD installations on my amd64 FreeBSD >> system that way without much in the way of trouble. Haven't had >> to do it for a while, though, so perhaps it's all changed. I >> wouldn't hate to discover that FreeBSD can do that too, >> though... > > We don't have this yet, but lots of people would like to see this (just > not quite enough to do it yet :). I've used netbsd and didn't find the unprivileged build process as useful as I expected but I'm certainly a fan of eliminating root use. I recently added makefs to the base system which simplifies setting up a cross-devel environment but we still lack bi-endian native filesystem support. Otherwise the key issues in improving cross-build support are: ports and requiring freebsd as the build host. With the advent of virtual machines however the build host issue is less critical. Sam From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 05:46:09 2009 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 82AB81065674 for ; Thu, 15 Jan 2009 05:46:09 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv01p.mx.bigpond.com (nschwqsrv01p.mx.bigpond.com [61.9.189.231]) by mx1.freebsd.org (Postfix) with ESMTP id 10CAD8FC12 for ; Thu, 15 Jan 2009 05:46:08 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas04p.mx.bigpond.com with ESMTP id <20090115031920.EYKE12089.nschwmtas04p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Thu, 15 Jan 2009 03:19:20 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090115031920.UJVP22733.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 15 Jan 2009 03:19:20 +0000 Received: (qmail 53221 invoked by uid 501); 15 Jan 2009 03:18:47 -0000 Date: Thu, 15 Jan 2009 14:18:47 +1100 From: Andrew Reilly To: Peter Jeremy Message-ID: <20090115031847.GA52343@duncan.reilly.home> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090114211616.GC16116@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.496EAB38.0092,ss=1,fgs=0 Cc: Andrew Hotlab , freebsd-amd64@freebsd.org, freebsd-i386@amd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD 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, 15 Jan 2009 05:46:09 -0000 On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote: > This won't work because install{world,kernel} uses programs (under > /usr/obj) that were built to run on the build system (amd64 in > your case) and so won't run on the target (i386) system. > > The supported approach is to NFS mount the target machines onto the > build machine and run "make DESTDIR=/mount/point install{world,kernel}" > on the build machine. Note that this will report errors since NFS > cannot handle UFS flags - you will need to manually remove/add schg flags. Is there any reason (apart from using more space on the build machine) not to install to a DESTDIR (not /) on the build machine, and then tar/pax/cpio that tree across to the client system? Presumably something like that must be done for the distribution builds that go into making the CD and DVD images. NetBSD has (had? it's been a while since I looked) a cool mechanism that allowed the whole tree to be built (and "installed" to a DESTDIR) without root permissions, using a variation on install that copied the file as the running user and recorded the intended user/group/mod/flags in an mtree file. Then a subsequent task created a tarball that contained the file contents and the mtree permissions, all as a non-root user. So you don't even need to muck about with root-over-nfs issues for deployment: just log into the client and untar the distribution over the network (as root). Very, very neat, IMO. I used to build embedded i386 NetBSD installations on my amd64 FreeBSD system that way without much in the way of trouble. Haven't had to do it for a while, though, so perhaps it's all changed. I wouldn't hate to discover that FreeBSD can do that too, though... Cheers, Andrew From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 14:48:24 2009 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 DB86E1065680 for ; Thu, 15 Jan 2009 14:48:24 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 98E448FC16 for ; Thu, 15 Jan 2009 14:48:24 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so437890ywe.13 for ; Thu, 15 Jan 2009 06:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=6Pqi1MbGS35lMcc8rFw4obSrifI9PN4XSYH6YdV4U0A=; b=B9VdTKiXld3XbGqwARhmm/PTHgSE1A89UDiSnf2SGEgX8xjXSC6R+rOK+bNuqjVX7+ iu5FyA6Lv1FcT0wfc27GGALlFJA4JWupEFRYZS8kuzHTK+qy9eVkbxL8+OtkcTz1aeIX zxYuKUT8HUhV0tqaXKe+OGbTwpogRdnla1wzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KgV05w+p+95cFXxLb4xCVNOJwDfexAisz1rL8izYhVMWPJjByMirMb8LFUit35f8it T6Lkf7bUaJlbqT/24txVqXmK8S323LUht4vTUlbE5x+bzCdc6dv5yEYZ3ghB7BX6nOVA LvEZWjoUbQcE4EthcUa4lWqWFq0mN3hQIs9H0= MIME-Version: 1.0 Received: by 10.143.6.1 with SMTP id j1mr541880wfi.152.1232029138758; Thu, 15 Jan 2009 06:18:58 -0800 (PST) Date: Thu, 15 Jan 2009 19:48:58 +0530 Message-ID: <251d650c0901150618o7a460083i2caab3982dce133a@mail.gmail.com> From: Mehul Chadha To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: doubts regarding System Initialization working (SYSINIT) 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, 15 Jan 2009 14:48:25 -0000 Hello all, I have been browsing through the FreeBSD kernel's source code trying to understand its working . In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects are sorted using bubble sort and then they are executed in order. My doubt is that we have declared the pointer to the struct sysinit as const pointer to a const in the macro definition of SYSINIT ie when the macro SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is expanded completely we get the following static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST, (sysinit_cfunc_t)(sysinit_nfunc_t)kmeminit, ((void *)(((void *)0))) }; static void const * const __set_sysinit_set_sym_kmem_sys_init __attribute__((__section__("set_" "sysinit_set"))) __attribute__((__used__)) = &kmem_sys_init; Here we see that the pointer is of type const and to a const but when we sort and swap using *sipp=*xipp; We are trying to change the address of const pointer to a new address in which case it should segfault but it works fine. Why does it not segfault it seems I have not understood the concept behind using const *const... I will be very thankful if you can help me with it. Regards, Mehul From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 18:09:00 2009 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 07ADB10656C4 for ; Thu, 15 Jan 2009 18:09:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BB7018FC18 for ; Thu, 15 Jan 2009 18:08:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0FI7vIU074843; Thu, 15 Jan 2009 11:07:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 15 Jan 2009 11:08:24 -0700 (MST) Message-Id: <20090115.110824.298933043.imp@bsdimp.com> To: stb@lassitu.de From: "M. Warner Losh" In-Reply-To: References: <496C8C6A.2030708@icyb.net.ua> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: avg@icyb.net.ua, freebsd-arch@freebsd.org Subject: Re: smb(4): address format 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, 15 Jan 2009 18:09:00 -0000 In message: Stefan Bethke writes: : Am 13.01.2009 um 13:43 schrieb Andriy Gapon: : : > So, in practice, there two conventions of specifying a slave address: : > either as 0XXXXXXXb or XXXXXXX0b. : : Device datasheets generally specify the hard-wired or configurable : address as a bit string, with a slight preference to format that as : bbbb bbb. : : > In wider world 0XXXXXXXb format seems to be preferred, Linux also : > sticks : > to it. : : I personally find having the address right-aligned a sensible choice. : I think of the address as logical unit, and normally would rather have : the SMBus bit banging abstracted away by the driver/hardware. The format that is preferred on FreeBSD is xxxxxxxx0b. That's the format that the existing IIC bridge drivers use and deal with. I've not looked at the SMB drivers, but I went through all the iic bridge drivers in the 6.x time frame and made sure they were all consistent. If I missed the smb drivers, that's my bad. I could find no evidence that there was a format that was more preferred apart from the dozen data sheets that I'd read at the time which used the xxxxxxx0b. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 21:01:31 2009 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 5BE671065670 for ; Thu, 15 Jan 2009 21:01:31 +0000 (UTC) (envelope-from do-1978-7023208-1286809-12--freebsd-arch.freebsd.org@rt.emm08.net) Received: from pm49-201.do02.net (pm49-201.do02.net [80.118.49.201]) by mx1.freebsd.org (Postfix) with ESMTP id AFFB08FC17 for ; Thu, 15 Jan 2009 21:01:28 +0000 (UTC) (envelope-from do-1978-7023208-1286809-12--freebsd-arch.freebsd.org@rt.emm08.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dk; d=jarfoval.fr; h=Message-Id:Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:List-Unsubscribe:From:To:Date:Subject; i=securitasdirect@jarfoval.fr; bh=IkQDFJ8puv74bsITSM0J0FS67E4=; b=u11f5ZzPz95QVqUTOvA7gVJB9kWuDvQcU4QSu+zLgD4FS3Qvm1Gt0Eigmd0MrRaskdCSbwOG2vS5 8scRG69dId6tSxG428a9Wd+o4dQP6o+BnXtZqOQDbvi56Y1bZK2xFjBMI9Eo9nuxMVJVBAVsA4mC dI4ueDKwZQ6rr/6kVkg= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=dk; d=jarfoval.fr; b=J7SUTC5954PBWsTrWyEOi/oxG0DJvHsGxIoBSXLMsmnbIi5bV3tatHe/GmYlx4fc99lJiKCL4BIk TzDhpPiSv3wkSI1Uc6/AbhTzuPjRgqhvSLhf0wkkOejiXrG5EMjf0JqlaMaLJS/fmXNibvFW2uC3 xuGmQDNMZ0lEZd53ipU=; Message-Id: Content-Transfer-Encoding: 8bit X-CAMPAIGN-ID: 1978-7023208-1286809 X-Mailer: DO v1978.b7023208.c1286809 From: "Securitas Direct" To: freebsd-arch@freebsd.org Date: Thu, 15 Jan 2009 21:50:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: =?iso-8859-1?q?La_s=E9curit=E9_avant_tout?= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Securitas Direct List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 21:01:31 -0000 Si vous ne pouvez pas voir correctement ce message, [1]cliquez ici [2][emailwebreflexe_01.gif] [3][emailwebreflexe_02.gif] [4][emailwebreflexe_03.gif] [5][emailwebreflexe_04.gif] [6][emailwebreflexe_05.gif] [7][emailwebreflexe_06.gif] [8][emailwebreflexe_07.gif] Société titulaire de l'autorisation administrative préfectorale de la Préfecture d'ANTONY n°2004/057du 01/09/04 Securitas Direct : SAS au capital de 1 537 424 euros - RCS B 345 006 027 - n'0 TVA : FR 60 345 006 027 - 1 Centrale Parc - Avenue Sully Prud'homme - 92290 Châtenay Malabry Autorisation Administrative du 16 novembre 1992 - Loi 83629 du 12 Juillet 1983, Art. 8: «L'autorisation administrative préalable ne confère aucun caractère officiel à l'entreprise ou aux personnes qui en bénéficient. Elle n'engage en aucune manière la responsabilité des pouvoirs publics.» Photos et documents non contractuels SD DEP 11/07. www.securitasdirect.fr Pour ne plus recevoir nos messages : [9]désinscription References 1. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 2. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 3. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 4. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 5. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 6. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 7. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 8. http://url.jarfoval.fr/id.asp?l=51481-7023208-1286809-1978-0 9. http://url.jarfoval.fr/id.asp?l=51482-7023208-1286809-1978-0&id=1286809-1978-7023208-1b7fd7e8&res=fr From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 23:09:53 2009 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 EDB491065674; Thu, 15 Jan 2009 23:09:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 805B08FC14; Thu, 15 Jan 2009 23:09:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0FN9och021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 10:09:50 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n0FN9nOf091640; Fri, 16 Jan 2009 10:09:49 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n0FN9njx091634; Fri, 16 Jan 2009 10:09:49 +1100 (EST) (envelope-from peter) Date: Fri, 16 Jan 2009 10:09:49 +1100 From: Peter Jeremy To: Andrew Hotlab Message-ID: <20090115230949.GD16116@server.vk2pj.dyndns.org> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CblX+4bnyfN0pR09" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD 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, 15 Jan 2009 23:09:55 -0000 --CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jan-15 01:12:03 +0000, Andrew Hotlab wr= ote: >Ok, so I think that in a production environment I should deploy one builde= r machine >for each target architecture I have to support on my network... I'm right? A single build machine can cross-build for multiple environments so you really only need one machine. >One last question: I would expect the same issues if I wish to to support = many >FreeBSD releases running of one single type of architecture? (i.e.: both b= uilder >and targets are amd64 machines, but I run RELENG_7 on the builder and >RELENG_6_4 and RELENG_7_1 on the targets) In general, backward compatibility is supported, so a world built on a RELENG_7 box should be able to be installed by a RELENG_7_1 target (though not by a RELENG_6_4 target). And you can run into he same problem with different i386 variants - if your build machine is built with (eg) P4 options than a generic world built by that box cannot be installed by (eg) a P2 due to instruction differences. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklvwj0ACgkQ/opHv/APuIegpACfWKtWC+t/iESLJVjpRQ6mq/lX JPYAmQHdSSR1/AG6M5P0NktdAGB8PkLm =xJ6f -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 16 01:15:03 2009 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 F157A106564A; Fri, 16 Jan 2009 01:15:03 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc3-s18.col0.hotmail.com (col0-omc3-s18.col0.hotmail.com [65.55.34.157]) by mx1.freebsd.org (Postfix) with ESMTP id CD20E8FC13; Fri, 16 Jan 2009 01:15:03 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W37 ([65.55.34.136]) by col0-omc3-s18.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 17:15:03 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Fri, 16 Jan 2009 01:15:03 +0000 Importance: Normal In-Reply-To: <20090115230949.GD16116@server.vk2pj.dyndns.org> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> <20090115230949.GD16116@server.vk2pj.dyndns.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2009 01:15:03.0391 (UTC) FILETIME=[DC146EF0:01C97777] Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD 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, 16 Jan 2009 01:15:04 -0000 > Date: Fri=2C 16 Jan 2009 10:09:49 +1100 > From: peterjeremy@optushome.com.au > > On 2009-Jan-15 01:12:03 +0000=2C Andrew Hotlab wrote: >>Ok=2C so I think that in a production environment I should deploy one bui= lder machine >>for each target architecture I have to support on my network... I'm right= ? > > A single build machine can cross-build for multiple environments so you > really only need one machine. > Yes it's true=2C but the limitation about UFS flags over NFS will force me = to make some manual operations and=2C even if I'll successfully script them=2C it will t= urn to increase the "total cost" of that solution... so I'd prefer to have a build machine for = each supported Tier1 architecture=2C if this can let me "sleep better at night". I don't c= onsider this a big issue: after all=2C I feel the need of a builder machine because I have a l= ot of physical machines to update... I can surely dedicate a couple of them (maybe a singl= e amd64 in a dual-boot scenario with both i386 and amd64 FreeBSD versions)! :) >>One last question: I would expect the same issues if I wish to to support= many >>FreeBSD releases running of one single type of architecture? (i.e.: both = builder >>and targets are amd64 machines=2C but I run RELENG_7 on the builder and >>RELENG_6_4 and RELENG_7_1 on the targets) > > In general=2C backward compatibility is supported=2C so a world built on = a > RELENG_7 box should be able to be installed by a RELENG_7_1 target > (though not by a RELENG_6_4 target). And you can run into he same > problem with different i386 variants - if your build machine is built > with (eg) P4 options than a generic world built by that box cannot be > installed by (eg) a P2 due to instruction differences. > So I have to experiment a little to better understand what can be safely do= ne and what it would be "at risk". Maybe if worst comes to worst I'll have to = maintain a builder for each single architecture and major FreeBSD branch. It could b= e not impossible if I'll decide to support legacy releases only on older i386= hardware. Thank you so much for your help! Andrew _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Space= s. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.= aspx&mkt=3Den-us= From owner-freebsd-arch@FreeBSD.ORG Fri Jan 16 09:50:16 2009 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 5B25D106571B; Fri, 16 Jan 2009 09:50:16 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [62.111.66.10]) by mx1.freebsd.org (Postfix) with ESMTP id DC89A8FC26; Fri, 16 Jan 2009 09:50:15 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [192.168.64.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTP id 1A1612EB862; Fri, 16 Jan 2009 10:32:48 +0100 (CET) Received: from amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [IPv6:2001:4068:10:1::201]) by m.cksoft.de (Postfix) with ESMTP id 36816ED04B; Fri, 16 Jan 2009 10:32:48 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([192.168.64.204]) by amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [192.168.64.201]) (amavisd-new, port 10024) with ESMTP id wFKyk25yLDZm; Fri, 16 Jan 2009 10:32:40 +0100 (CET) Received: from tapio.cksoft.de (tapio.cksoft.de [IPv6:2001:4068:10:1:218:8bff:fe76:5932]) by m.cksoft.de (Postfix) with ESMTP id 3213BECFB4; Fri, 16 Jan 2009 10:32:39 +0100 (CET) Received: by tapio.cksoft.de (Postfix, from userid 1000) id A6732B8DC; Fri, 16 Jan 2009 10:32:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tapio.cksoft.de (Postfix) with ESMTP id 98DCDB809; Fri, 16 Jan 2009 10:32:39 +0100 (CET) Date: Fri, 16 Jan 2009 10:32:39 +0100 (CET) From: Christian Kratzer X-X-Sender: ck@tapio.cksoft.de To: Andrew Hotlab In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-i386@amd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 09:50:17 -0000 Hi, On Wed, 14 Jan 2009, Andrew Hotlab wrote: > >> From: andrew.hotlab@hotmail.com >> To: freebsd-questions@freebsd.org >> Subject: Builder for many architectures and releases >> Date: Sat, 10 Jan 2009 02:37:37 +0000 >> >> [...] I looked for any documentation about setup a FreeBSD builder machine which will track sources and build binaries for all the hardware platform and OS releases I need to support in my network. I have found some interesting articles (http://www.onlamp.com/pub/a/bsd/2006/04/13/freebsd-build-system.html - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html), but nothing which actually addresses my needs. [...] >> > > At this time, I've tried to build RELENG_7_1 for the i386 architecture using an amd64 machine (running RELENG_7_0 for amd64) then, exporting /usr/src and /usr/obj via NFS in read-only mode to target machines, I've experienced a lot of troubles trying to install both kernel and world, which made impossible for me to install FreeBSD on target i386 machines. > Can anyone kindly confirm that it's a supported procedure to compile FreeBSD for a Tier1 architecture by using another Tier1-architecture machine? Maybe I didn't understood documentation or I'm missing some essential steps in the build process? as you already found out this does not work as the crossbuild process will build the native host tools in /usr/obj and the target system binaries in /usr/obj/i386. On recent RELENG_7 or HEAD machines you should be able to build in an i386 chroot. This would produce a clean /usr/obj you can copy to your i386 machines and install from there. The hack to enable building in an i386 chroot is to set UNAME_m and UNAME_p to i386. I use following in the chroots .cshrc setenv UNAME_m i386 setenv UNAME_p i386 This will avoid any crossbuild magic and you will be able to build as if on an i386 machine. This of course only works for the amd64, i386 combination. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Schwarzwaldstr. 31 Phone: +49 7452 889 135 D-71131 Jettingen Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer From owner-freebsd-arch@FreeBSD.ORG Fri Jan 16 10:24:47 2009 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 47719106564A; Fri, 16 Jan 2009 10:24:47 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc1-s7.col0.hotmail.com (col0-omc1-s7.col0.hotmail.com [65.55.34.17]) by mx1.freebsd.org (Postfix) with ESMTP id 254238FC0C; Fri, 16 Jan 2009 10:24:46 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W78 ([65.55.34.9]) by col0-omc1-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 02:24:46 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Fri, 16 Jan 2009 10:24:46 +0000 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2009 10:24:46.0794 (UTC) FILETIME=[A7B852A0:01C977C4] Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD 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, 16 Jan 2009 10:24:47 -0000 > Date: Fri=2C 16 Jan 2009 10:32:39 +0100 > From: ck-lists@cksoft.de > > On Wed=2C 14 Jan 2009=2C Andrew Hotlab wrote: > >> At this time=2C I've tried to build RELENG_7_1 for the i386 architecture= using an amd64 >> machine (running RELENG_7_0 for amd64) then=2C exporting /usr/src and /u= sr/obj via >> NFS in read-only mode to target machines=2C I've experienced a lot of tr= oubles trying to >> install both kernel and world=2C which made impossible for me to install= FreeBSD on >> target i386 machines. >> Can anyone kindly confirm that it's a supported procedure to compile Fre= eBSD for >> a Tier1 architecture by using another Tier1-architecture machine? Maybe = I didn't >> understood documentation or I'm missing some essential steps in the buil= d process? > > as you already found out this does not work as the crossbuild process > will build the native host tools in /usr/obj and the target system > binaries in /usr/obj/i386. > > On recent RELENG_7 or HEAD machines you should be able to build > in an i386 chroot. This would produce a clean /usr/obj you > can copy to your i386 machines and install from there. > Sorry for my stupid question: I'll do the right thing if I'll build an i386= jail chroot/jail on the amd64 builder host with the following commands? (grabbed from the FreeBSD H= andbook) # cd /usr/src # make buildworld TARGET=3Di386 # make installworld TARGET=3Di386 DESTDIR=3D/path-to-jail # cd etc/ # make distribution DESTDIR=3D/path-to-jail # mount -t devfs devfs /path-to-jail/dev > The hack to enable building in an i386 chroot is to set UNAME_m > and UNAME_p to i386. I use following in the chroots .cshrc > > setenv UNAME_m i386 > setenv UNAME_p i386 > > This will avoid any crossbuild magic and you will be able to build > as if on an i386 machine. > > This of course only works for the amd64=2C i386 combination. Wonderful=2C I'll try this as soon as possible. Thank you! _________________________________________________________________ News=2C entertainment and everything you care about at Live.com. Get it now= ! http://www.live.com/getstarted.aspx= From owner-freebsd-arch@FreeBSD.ORG Fri Jan 16 10:57:02 2009 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 A7F1D10657C3; Fri, 16 Jan 2009 10:57:02 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [62.111.66.10]) by mx1.freebsd.org (Postfix) with ESMTP id 550B28FC12; Fri, 16 Jan 2009 10:57:02 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [192.168.64.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTP id C8BAA2EB925; Fri, 16 Jan 2009 11:57:00 +0100 (CET) Received: from amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [IPv6:2001:4068:10:1::201]) by m.cksoft.de (Postfix) with ESMTP id 6DC50ED02C; Fri, 16 Jan 2009 11:56:59 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([192.168.64.204]) by amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [192.168.64.201]) (amavisd-new, port 10024) with ESMTP id YXBu0kI3xcO2; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Received: from tapio.cksoft.de (tapio.cksoft.de [IPv6:2001:4068:10:1:218:8bff:fe76:5932]) by m.cksoft.de (Postfix) with ESMTP id AB21CED029; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Received: by tapio.cksoft.de (Postfix, from userid 1000) id 84288B8DC; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tapio.cksoft.de (Postfix) with ESMTP id 767EEB809; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Date: Fri, 16 Jan 2009 11:56:55 +0100 (CET) From: Christian Kratzer X-X-Sender: ck@tapio.cksoft.de To: Andrew Hotlab In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 10:57:03 -0000 Hi, On Fri, 16 Jan 2009, Andrew Hotlab wrote: > Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the > amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook) > # cd /usr/src > # make buildworld TARGET=i386 > # make installworld TARGET=i386 DESTDIR=/path-to-jail > # cd etc/ > # make distribution DESTDIR=/path-to-jail > # mount -t devfs devfs /path-to-jail/dev yes that should do it but I think you can skip the cd etc/ part. make distribution should work from /usr/src >> The hack to enable building in an i386 chroot is to set UNAME_m >> and UNAME_p to i386. I use following in the chroots .cshrc >> >> setenv UNAME_m i386 >> setenv UNAME_p i386 >> >> This will avoid any crossbuild magic and you will be able to build >> as if on an i386 machine. >> >> This of course only works for the amd64, i386 combination. > Wonderful, I'll try this as soon as possible. Thank you! let us know if it works out. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Schwarzwaldstr. 31 Phone: +49 7452 889 135 D-71131 Jettingen Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer From owner-freebsd-arch@FreeBSD.ORG Fri Jan 16 13:17:35 2009 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 A53E11065679; Fri, 16 Jan 2009 13:17:35 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 97AAD8FC14; Fri, 16 Jan 2009 13:17:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA01024; Fri, 16 Jan 2009 15:17:27 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <497088E6.4020908@icyb.net.ua> Date: Fri, 16 Jan 2009 15:17:26 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: "M. Warner Losh" , freebsd-arch@freebsd.org References: <496C8C6A.2030708@icyb.net.ua> <20090115.110824.298933043.imp@bsdimp.com> In-Reply-To: <20090115.110824.298933043.imp@bsdimp.com> Content-Type: multipart/mixed; boundary="------------030501080701080500080601" Cc: Archie Cobbs Subject: Re: smb(4): address format 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, 16 Jan 2009 13:17:35 -0000 This is a multi-part message in MIME format. --------------030501080701080500080601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 15/01/2009 20:08 M. Warner Losh said the following: > The format that is preferred on FreeBSD is xxxxxxxx0b. That's the > format that the existing IIC bridge drivers use and deal with. I've > not looked at the SMB drivers, but I went through all the iic bridge > drivers in the 6.x time frame and made sure they were all consistent. > If I missed the smb drivers, that's my bad. > > I could find no evidence that there was a format that was more > preferred apart from the dozen data sheets that I'd read at the time > which used the xxxxxxx0b. What about the attached patch. It brings ichsmb in line with this format and also adds a simple check into smb(4). -- Andriy Gapon --------------030501080701080500080601 Content-Type: text/plain; name="ichsmb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ichsmb.diff" diff --git a/sys/dev/ichsmb/ichsmb.c b/sys/dev/ichsmb/ichsmb.c index 9c60df7..75863e4 100644 --- a/sys/dev/ichsmb/ichsmb.c +++ b/sys/dev/ichsmb/ichsmb.c @@ -182,7 +182,7 @@ ichsmb_quick(device_t dev, u_char slave, int how) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_QUICK; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | (how == SMB_QREAD ? + slave | (how == SMB_QREAD ? ICH_XMIT_SLVA_READ : ICH_XMIT_SLVA_WRITE)); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT, ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd); @@ -208,7 +208,7 @@ ichsmb_sendb(device_t dev, u_char slave, char byte) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_WRITE); + slave | ICH_XMIT_SLVA_WRITE); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, byte); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT, ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd); @@ -230,7 +230,7 @@ ichsmb_recvb(device_t dev, u_char slave, char *byte) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_READ); + slave | ICH_XMIT_SLVA_READ); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT, ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd); if ((smb_error = ichsmb_wait(sc)) == SMB_ENOERR) @@ -253,7 +253,7 @@ ichsmb_writeb(device_t dev, u_char slave, char cmd, char byte) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE_DATA; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_WRITE); + slave | ICH_XMIT_SLVA_WRITE); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, byte); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT, @@ -277,7 +277,7 @@ ichsmb_writew(device_t dev, u_char slave, char cmd, short word) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_WORD_DATA; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_WRITE); + slave | ICH_XMIT_SLVA_WRITE); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, word & 0xff); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D1, word >> 8); @@ -301,7 +301,7 @@ ichsmb_readb(device_t dev, u_char slave, char cmd, char *byte) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BYTE_DATA; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_READ); + slave | ICH_XMIT_SLVA_READ); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT, ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd); @@ -324,7 +324,7 @@ ichsmb_readw(device_t dev, u_char slave, char cmd, short *word) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_WORD_DATA; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_READ); + slave | ICH_XMIT_SLVA_READ); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT, ICH_HST_CNT_START | ICH_HST_CNT_INTREN | sc->ich_cmd); @@ -352,7 +352,7 @@ ichsmb_pcall(device_t dev, u_char slave, char cmd, short sdata, short *rdata) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_PROC_CALL; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_WRITE); + slave | ICH_XMIT_SLVA_WRITE); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, sdata & 0xff); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D1, sdata >> 8); @@ -403,7 +403,7 @@ ichsmb_bwrite(device_t dev, u_char slave, char cmd, u_char count, char *buf) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BLOCK; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_WRITE); + slave | ICH_XMIT_SLVA_WRITE); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, count); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_BLOCK_DB, buf[0]); @@ -434,7 +434,7 @@ ichsmb_bread(device_t dev, u_char slave, char cmd, u_char *count, char *buf) mtx_lock(&sc->mutex); sc->ich_cmd = ICH_HST_CNT_SMB_CMD_BLOCK; bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_XMIT_SLVA, - (slave << 1) | ICH_XMIT_SLVA_READ); + slave | ICH_XMIT_SLVA_READ); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CMD, cmd); bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_D0, *count); /* XXX? */ bus_space_write_1(sc->io_bst, sc->io_bsh, ICH_HST_CNT, diff --git a/sys/dev/smbus/smb.c b/sys/dev/smbus/smb.c index 6fce9b2..6e991ea 100644 --- a/sys/dev/smbus/smb.c +++ b/sys/dev/smbus/smb.c @@ -195,6 +195,10 @@ smbioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct thread *t parent = device_get_parent(smbdev); + /* Make sure that LSB bit is cleared. */ + if (s->slave & 0x1) + return (EINVAL); + /* Allocate the bus. */ if ((error = smbus_request_bus(parent, smbdev, (flags & O_NONBLOCK) ? SMB_DONTWAIT : (SMB_WAIT | SMB_INTR)))) --------------030501080701080500080601-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 17 01:25:53 2009 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 6E61A10656C7; Sat, 17 Jan 2009 01:25:53 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc1-s13.col0.hotmail.com (col0-omc1-s13.col0.hotmail.com [65.55.34.23]) by mx1.freebsd.org (Postfix) with ESMTP id 446FB8FC12; Sat, 17 Jan 2009 01:25:53 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W17 ([65.55.34.9]) by col0-omc1-s13.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 17:25:53 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Sat, 17 Jan 2009 01:25:53 +0000 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2009 01:25:53.0465 (UTC) FILETIME=[89F79A90:01C97842] Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD 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, 17 Jan 2009 01:25:57 -0000 > Date: Fri=2C 16 Jan 2009 11:56:55 +0100 > From: ck-lists@cksoft.de > > On Fri=2C 16 Jan 2009=2C Andrew Hotlab wrote: > >> Sorry for my stupid question: I'll do the right thing if I'll build an i= 386 jail chroot/jail on the >> amd64 builder host with the following commands? (grabbed from the FreeBS= D Handbook) >> # cd /usr/src >> # make buildworld TARGET=3Di386 >> # make installworld TARGET=3Di386 DESTDIR=3D/path-to-jail >> # cd etc/ >> # make distribution DESTDIR=3D/path-to-jail >> # mount -t devfs devfs /path-to-jail/dev > > yes that should do it but I think you can skip the cd etc/ part. > make distribution should work from /usr/src > >>> The hack to enable building in an i386 chroot is to set UNAME_m >>> and UNAME_p to i386. I use following in the chroots .cshrc >>> [...] >>> This of course only works for the amd64=2C i386 combination. >> Wonderful=2C I'll try this as soon as possible. Thank you! > > let us know if it works out. I've build and exported RELENG_7_0 into an i386 jail running on amd64 hardw= are=2C then I mounted sources and binaries on a RELENG_6_4/i386 machine and I have been a= ble to successfully upgrade without any trouble!! (only some warnings were display= ed installing the kernel=2C but that's a correct behaviour of the upgrade procedure=2C as= pointed out in this post: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/0579= 63.html) Thank you so much=2C Christian! I'm thinking that it would be a great thing to prepare some materials expla= ining the methods for maintaining a managed FreeBSD infrastructure in a corporate production = environment. A lot of sysadmins are afraid that they'll have to spend so much time in soft= ware management tasks if they put FreeBSD in production for business applications=2C but it= seems that only a little of knowledge is required to manage such and environment obtaining a good TC= O. At present time I'm too much engaged with a lot of projects to be able to p= roduce any docs=2C but I'll surely advocate FreeBSD in such business scenarios! _________________________________________________________________ More than messages=96check out the rest of the Windows Live=99. http://www.microsoft.com/windows/windowslive/= From owner-freebsd-arch@FreeBSD.ORG Sat Jan 17 12:06:42 2009 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 1C5711065986; Sat, 17 Jan 2009 12:06:42 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc1-s5.col0.hotmail.com (col0-omc1-s5.col0.hotmail.com [65.55.34.15]) by mx1.freebsd.org (Postfix) with ESMTP id E02908FC1C; Sat, 17 Jan 2009 12:06:41 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W79 ([65.55.34.7]) by col0-omc1-s5.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Jan 2009 04:06:42 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Sat, 17 Jan 2009 12:06:41 +0000 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2009 12:06:42.0157 (UTC) FILETIME=[0F2C69D0:01C9789C] Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD 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, 17 Jan 2009 12:07:07 -0000 > From: andrew.hotlab@hotmail.com > Date: Sat=2C 17 Jan 2009 01:25:53 +0000 > >> >> On Fri=2C 16 Jan 2009=2C Andrew Hotlab wrote: >> >>> Sorry for my stupid question: I'll do the right thing if I'll build an = i386 jail chroot/jail on the >>> amd64 builder host with the following commands? (grabbed from the FreeB= SD Handbook) >>> # cd /usr/src >>> # make buildworld TARGET=3Di386 >>> # make installworld TARGET=3Di386 DESTDIR=3D/path-to-jail >>> # cd etc/ >>> # make distribution DESTDIR=3D/path-to-jail >>> # mount -t devfs devfs /path-to-jail/dev >> >> yes that should do it but I think you can skip the cd etc/ part. >> make distribution should work from /usr/src >> I missed to write that the sequence of commands that I had to issue in orde= r to create the i386 jail was a little different from what I wrote yesterday. I had to issu= e the following command to successfully make distribution: # make distribution TARGET=3Di386 DESTDIR=3D/path-to-jail Greetings. Andrew _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Space= s. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.= aspx&mkt=3Den-us=