Date: Tue, 28 Jan 2003 16:49:55 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: current@FreeBSD.ORG Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030128164955.A7369@FreeBSD.org> In-Reply-To: <20030129004006.GA945@athlon.pn.xcllnt.net>; from marcel@xcllnt.net on Tue, Jan 28, 2003 at 04:40:06PM -0800 References: <20030125153116.A25743@FreeBSD.org> <20030128.233856.71130419.nyan@jp.FreeBSD.org> <20030128120830.A81856@FreeBSD.org> <20030128225335.GB537@athlon.pn.xcllnt.net> <20030128151749.A831@FreeBSD.org> <20030128235528.GA844@athlon.pn.xcllnt.net> <20030128160936.A4252@FreeBSD.org> <20030129004006.GA945@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: Marcel Moolenaar <marcel@xcllnt.net> [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about "platforms". ] > > But > > that determines what <machine> is a link to, and files.<machine> that is > > read. So that means that we need to have <machine/*.h> stubbed in both > > <algor/> and <sgimips/>. Each of those defines the things they need to > > be defined, and then includes <mips/\&.h>. Even if we know that we never > > need to have any changes, or otherwise have the abstraction the wrong way > > around. It also means that you have to pull in the mips options and files > > list for both of those ports, and so on. So you end up having "machine > > $(MACHINE)" and having to explicitly inherit bit by bit everything that > > you may need into the meta-port (algor or sgimips -- $(MACHINE)), in an > > explicit manner. > > My way, <machine> is "mips" and the headers which provide tunables include > > <platform/\&.h>. Optional hardware for a given platform is pulled in via > > files.mips optional directives. Everything is less convoluted, IMHO. > > > > > No implementation details please. > > > > I did my best, but I still have to show that there are two explicit > > meta-ports. My previous email had no "implementation details", just > > general structure, and you rejected it, so I hope this is better. > > It's different :-) > > What I'm trying to get at is how sgimips is the same as algor and > likewise how it is different, independent as to how this would > be handled in our source tree. > For example: if they both use the same processor and instruction > set and have the same runtime specification, you can say that they > are both MIPS. The endianness is just a slight variation of the > general theme. Thus (in this case), ARCH=mips and MACH=algor or > MACH=sgimips... That's what I'm saying, yes. > So, given that we have MACHINE_ARCH and MACHINE already to our > disposal, I don't get the feeling that we are in need to add > something else because the problem space appears 2D, not 3D. > > Right? That's what I'm trying to do, in a clean way. See my "short version" message, if you like. -- 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?20030128164955.A7369>