Date: Sun, 26 Jan 2003 17:28:14 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: David O'Brien <obrien@FreeBSD.org>, current@FreeBSD.org, Peter Wemm <peter@FreeBSD.org> Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030126172814.A20477@FreeBSD.org> In-Reply-To: <20030126234659.GB61926@dragon.nuxi.com>; from obrien@FreeBSD.org on Sun, Jan 26, 2003 at 03:46:59PM -0800 References: <20030125153116.A25743@FreeBSD.org> <20030126234659.GB61926@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: David O'Brien <obrien@FreeBSD.org> [ Data: 2003-01-26 ] [ Subjecte: Re: Patch to teach config(8) about "platforms". ] > On Sat, Jan 25, 2003 at 03:31:16PM -0800, Juli Mallett wrote: > > This patch is needed for the MIPS port's infrastructure, and will be > > needed for the PowerPC one, as given ports may support any number of > > platforms, on those architectures (and arguably, the same applies to > > i386 vs. pc98, but historically...). What it does is it sets up a > > build-time (and install-time, given right MACHINE_ARCH vs. MACHINE) > > <platform> include directory as an analogue to <machine>, where we > > need it. For kernels with a "platform" setting, it also sets the > > appropriate option for it. For example "platform sgimips" implies > > "options SGIMIPS". Below are patches to makefile glue and config(8) > > itself. > > For clarity, this is used in cases where the platform may define its > > own values that a header needs, and as such, you might see something > > in <machine/endian.h> like: > > #include <platform/endian.h> > > I may not be fully following you, but I'd like to keep such changes down > to what is absolutely necessary. Can you show your GENERIC sgimips > config? Also show an example of where one would need a platform/endian.h > on both powerpc (which is far enough along to discuss this need) and mips > (which I think we should wait later until the port is officially in CVS). > I have a guess, but I want to make absolutely sure. You wouldn't need endian.h for PowerPC, but there are other cases it would be useful. You'd have to ask Benno. I discussed this with him long ago. But already PowerPC supports both the PSim and the PowerMac, so certainly there are cases they probably have where such would be useful to avoid ifdef hell in the headers. As for mips, if we ever supported e.g. the NT MIPS boxes they are little endian, whereas other stuff is BE. The ratio is nearly 1:1 in embedded devices istr. This is infrastructure. As for my GENERIC, this is what I'm working toward right now: %%% %%% And as for discussing it, it doesn't matter right now, it's just infrastructure for something. If you need for me to provide more detailed cases of where it could be useful... Since I don't want to get any details wrong, I'll just make this up. Let's say the port to FooArch supports FooHPC (a handheld) and FooW (a workstation). On the FooHPC, the cache works is a funky way because of how memory is accessed, whereas on the FooW, it behaves more for what works for a workstation. Because of this, <machine/pmap.h> includes <platform/pmap.h> to pull in the defines that control the cache model, etc., especially since there is a third-party making FooSU (a 1U rackmount server) and FooC (a clustered solution) machines, and porting FreeBSD to them, and the characteristics are a well defined superset of one or the other existing configurations. Rather than having to clutter up the <machine/pmap.h> and grow the diffs that aren't specific to this platform, like this: #if defined(FooHPC) || defined(FooC) #define FOO_CACHE_WB FOO_CACHE_WB_MEMBAR_WRITE #else #define FOO_CACHE_WB FOO_CACHE_WB_MEMBAR_ALL #endif their <platform/pmap.h> just defines FOO_CACHE_WB to whatever is Correct, and possibly, <machine/pmap.h> falls back to the most logical default. Remember that particularly wrt MIPS (and I'd bet ARM, should it ever happen, and to a lesser extent with PowerPC) we're dealing with supporting a MACHINE_ ARCH, as well as at least a few MACHINEs, and there's much 3rd-party interest in private MACHINE support, etc., and so logical abstractions for this sort of thing in a header sense is certainly neater than all the other munging. And there was a lot of concern about supporting one or the other machines, or any given embedded configuration, and I think this makes sense, and avoids the clutter of what NetBSD does (the MACHINE_ARCH is slave to the MACHINE port, as opposed to having a MACHINE_ARCH which *may support* given other MACHINEs). Thanx, juli. -- Juli Mallett <jmallett@FreeBSD.org> AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030126172814.A20477>