From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 23 16:56:21 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3C8F16A4DF for ; Sun, 23 Jul 2006 16:56:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C61743D4C for ; Sun, 23 Jul 2006 16:56:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6NGtUdH029743; Sun, 23 Jul 2006 10:55:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 23 Jul 2006 10:55:49 -0600 (MDT) Message-Id: <20060723.105549.2106235963.imp@bsdimp.com> To: tyler@bleepsoft.com From: "M. Warner Losh" In-Reply-To: <3320CEAC-8A5C-407D-9867-C2A22820A599@bleepsoft.com> References: <7ADD22A7-42DE-49D8-B411-DBA4CB2FA0CD@bleepsoft.com> <20060723100223.GB24435@gothmog.pc> <3320CEAC-8A5C-407D-9867-C2A22820A599@bleepsoft.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 23 Jul 2006 10:55:31 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: Building a sandboxed kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 16:56:21 -0000 In message: <3320CEAC-8A5C-407D-9867-C2A22820A599@bleepsoft.com> "R. Tyler Ballance" writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : >> : >> Between varying versions of userland tools (like config(8)) and path : >> troubles, I'm wondering what tips anybody has to doing non-standard : >> builds of the kernel (non-standard being not in /usr/src and not the : >> host arch) : >> : >> Currently the make command I'm using, which doesn't work, is (/usr/ : >> obj is chmod'd 777): : >> : >> make TARGET_ARCH=iguana DESTDIR=/home/tyler/iguana buildkernel : >> : >> Any suggestions? : > : > You don't have to use /usr/obj for all your builds: : > : > % mkdir -p /home/tyler/obj/iguana : > % env MAKEOBJDIRPREFIX=/home/tyler/obj/iguana \ : > make TARGET_ARCH=iguana \ : > DESTDIR=/home/tyler/iguana \ : > buildkernel : > : > The trick here is to use MAKEOBJDIRPREFIX to change the default object : > directory prefix from `/usr/obj' to whatever suits your own setup. : : : This doesn't solve the problem of different versions of userland : tools required. For example, my machne is RELENG_6, but I'm : developing against the -CURRENT branch of code synced up in perforce. : Does one necessarily need a -CURRENT userland to develop with the - : CURRENT code base? All arguments of being able to test the code that : is built are moot since the testing of my code will all occur within : a virtualized (Qemu) machine environment. : : I'm sure the difference in versions between RELENG_6 and CURRENT : aren't too great, but what about developing with CURRENT code on : RELENG_5? I guess the basic question is, how can I maintain my normal : workstation environment while using a toolset appropriate for : building CURRENT? (Does it even matter really?) Doesn't matter. I often do the following: setenv TARGET arm # this may be iguana for you setenv TARGET_ARCH arm setenv MAKEOBJDIRPREFIX /home/imp/obj cd p4/imp_arm make buildworld make buildenv # from here on out is in a subshell cd ../arm/src/sys/arm/conf config KB920X cd ../compile/KB920X make depend && make You'll notice that I built in a tree that had all the arm patches applied, and got a 'buildenv' there, but then build the kernel out of a different tree. This is a -current p4 tree for both imp_arm and arm, but I do this on a RELENG_6 system. I've done it in the recent past on a 5.3 system too. TARGET is MACHINE and TARGET_ARCH is MACHINE_ARCH. MACHINE is the kernel architecture, while MACHINE_ARCH is the CPU architecture (TARGET_CPU is the specific CPU that we're optimizing for). Chances are excellent we'll have TARGET_ARCH armel and armeb shortly. Right now we have a hack ARM_BIG_ENDIAN used to control big vs little endian, but since MACHINE_ARCH gets encoded into packages, I think we need to move it there so binary packages do the right thing. But that's a WIP in my tree right now... Warner