Date: Mon, 18 Dec 2006 17:33:51 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Peter Grehan <grehan@FreeBSD.org> Cc: ppc@FreeBSD.org Subject: Re: Adding new PowerPC platforms to the build Message-ID: <D50A4BB7-68CA-4953-8956-7CE4B30EEA83@mac.com> In-Reply-To: <45873A21.8020304@freebsd.org> References: <DE8E70B1-9E3F-41E8-8502-AA374BFB150C@mac.com> <45873A21.8020304@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D50A4BB7-68CA-4953-8956-7CE4B30EEA83>