From owner-freebsd-ppc@FreeBSD.ORG Tue Dec 19 01:36:45 2006 Return-Path: X-Original-To: ppc@FreeBSD.org Delivered-To: freebsd-ppc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 462A716A415 for ; Tue, 19 Dec 2006 01:36:45 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7E9943CA6 for ; Tue, 19 Dec 2006 01:36:44 +0000 (GMT) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout12/MantshX 4.0) with ESMTP id kBJ1YdfO008888; Mon, 18 Dec 2006 17:34:39 -0800 (PST) Received: from [172.24.92.150] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id kBJ1YXXR028783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Dec 2006 17:34:37 -0800 (PST) In-Reply-To: <45873A21.8020304@freebsd.org> References: <45873A21.8020304@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Mon, 18 Dec 2006 17:33:51 -0800 To: Peter Grehan X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: ppc@FreeBSD.org Subject: Re: Adding new PowerPC platforms to the build X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 01:36:45 -0000 On Dec 18, 2006, at 5:02 PM, Peter Grehan wrote: > See below, I wouldn't want to have a compile-time option for this > unless it's absolutely necessary. Put all the CPU-model-specific > code in it's own source file, glue them together with linker sets, > and pick one at boot-time. If you only want one, then create a > custom config that only includes the one of interest. GENERIC can > have all of them, within reason. There's at least 1 gotcha: I think the ABI for embedded space is different from server space (Book III-E vs Book III-S). Think floating-point. MI code that is intended to run on a Book III-S ISA processor should use hardware FP. MI code that is intended to run on a Book III-E ISA processor cannot. This seems to indicate that we have more than 1 distinct PowerPC worlds and that it would not be beneficial to try to combine these into a single release or build. So, if we can use (say) MACHINE to indicate the ABI variant (either III-S or III-E, but maybe even VLE) then we at least separate these worlds and use dynamic linking, loading, KOBJ-ification et al for runtime selection of features and code blobs. In other words: what is the absolute minimum separation we need to introduce that yields reasonable generic behavior per class (if at all) and how do we implement that separation in the source tree. As you say, custom kernels and run-time tuning should allow us to handle variations within a single class. For example, the following seems quite user-friendly and intuitive: make release TARGET_ARCH=powerpc TARGET=server or make release TARGET_ARCH=powerpc TARGET=embedded and it does solve the biggest problem we're facing. Would this be so bad? Also, I don't want to assume that whatever we do should be done in the same way as pc98 and sun4u has been done. I think they have set a bad example. I pretty much assume that TARGET=foo would imply a directory foo under the TARGET_ARCH directory. In any case, I don't want to tie myself down to what's there. I want to explore what we like to be able to do and then fix FreeBSD to allow us to do it. -- Marcel Moolenaar xcllnt@mac.com