Date: Tue, 28 Jan 2003 16:40:06 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Juli Mallett <jmallett@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030129004006.GA945@athlon.pn.xcllnt.net> In-Reply-To: <20030128160936.A4252@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 28, 2003 at 04:09:36PM -0800, Juli Mallett wrote: > * De: Marcel Moolenaar <marcel@xcllnt.net> [ Data: 2003-01-28 ] > [ Subjecte: Re: Patch to teach config(8) about "platforms". ] > > On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote: > > > * De: Marcel Moolenaar <marcel@xcllnt.net> [ Data: 2003-01-28 ] > > > [ Subjecte: Re: Patch to teach config(8) about "platforms". ] > > > > > I just really would like things to be clean, and abstracted, and not waste > > > > > anyone's time. Why should we have to duplicate so much code? > > > > > > > > I'm not sure platform is the answer. We already have the distinction > > > > between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can > > > > do what you try to achieve with platform. Why add a "platform" > > > > keyword to config(8) if we already have the "machine" keyword? > > > > > > Because that requires us to do what pc98 does, which is to have the > > > meta-port be the master port, and include up into the arch-port, and > > > that means that either you have every header in the arch-port be > > > wrapped by the meta-port, as <machine> is the meta-port, or you just > > > copy everything and make local changes. > > > > I'm sorry, you use implications I don't see to come to a conclusion > > I don't get: > > > > Start with the beginning: We have MACHINE_ARCH and MACHINE. Can you > > represent the problem you're seeing with MIPS with two entities, > > namely MACHINE_ARCH and MACHINE? > > If yes, how exactly do these entities need to be defined in that case > > and how do they relate to each other. > > If no, explain why you need more entities to capture the problem. > > Sure, say we support sgimips and algor MACHINE's on the mips MACHINE_ARCH. > That's SGI workstations, which are big-endian and have ARCBIOS stuff, > and Algorithmics development boards, which support little-endian and > big-endian configurations. Obviously we have "machine mips", right? Hmmm... No so obvious. I would expect MACHINE_ARCH to be MIPS, which is implied by the implementation (ie /sys/mips; /sys/conf/files.mips) This leaves the machine keyword in the kernel config file free to be used for the platform/implementation. > 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... We have something like this for ia64. The processor can operate in BE and LE and emulates i386. Nonetheless, it's still the ia64 architecture. Hence, MACHINE_ARCH is ia64. Currently there are only 2 implementations of the processor and we don't care, but more are on their way. The architecture allows that. I would expect us to use the machine keyword in the kernel config file if we cannot capture all variations at the same time and are forced to make different machine targets. 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? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20030129004006.GA945>