Date: Tue, 28 Jan 2003 20:45:48 -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: <20030129044548.GI1016@athlon.pn.xcllnt.net> In-Reply-To: <20030128190158.A15778@FreeBSD.org> References: <20030128235528.GA844@athlon.pn.xcllnt.net> <20030128160936.A4252@FreeBSD.org> <20030129004006.GA945@athlon.pn.xcllnt.net> <20030128164955.A7369@FreeBSD.org> <20030129013537.GB1016@athlon.pn.xcllnt.net> <20030128174259.A10304@FreeBSD.org> <20030129021406.GD1016@athlon.pn.xcllnt.net> <20030128182013.A13422@FreeBSD.org> <20030129025124.GG1016@athlon.pn.xcllnt.net> <20030128190158.A15778@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 28, 2003 at 07:01:58PM -0800, Juli Mallett wrote: > * De: Marcel Moolenaar <marcel@xcllnt.net> [ Data: 2003-01-28 ] > [ Subjecte: Re: Patch to teach config(8) about "platforms". ] > > > > > We attach lots of meaning to MACHINE. You keep missing that that > > > > > is NOT the same as the "machine" keyword. > > > > > > > > And you keep missing that I don't assume that it cannot be made the > > > > same. That's why I ask about meaning and that's why I want things > > > > to be discussed on an abstract level. > > > > > > OK. Well, if you make them the same, you are hacking up an existing > > > thing to mean something vastly different, which IMO is ugly and > > > full of repetition, and wholly un-flesible. > > > > Ok, if making them the same means that we're changing the meaning of > > machine, then clearly you know what the meaning is now. Please > > tell me. > > Right now, it says where to get files, options, and Makefile. But is that the meaning or just the implementation? For pc98, machine is set to pc98 and what we build is a system that has MACHINE_ARCH=i386 and MACHINE=pc98. Right? For i386, machine is set to i386 and what we build is a system that has MACHINE_ARCH=i386 and MACHINE=i386. Right? Thus: machine identifies a variant for a particular architecture, right? The implementation is messy and I can understand that you don't want to do it the same way. See below. > In > the paradigm I chose to use, these are all part of the master port, > rather than the meta-port. Each machine is actually closer to > MACHINE_ARCH in intended meaning from config(8), as it is intended to > be related to the "cpu" directive, e.g. machine defines the architecture, > say, "mips", and to go with it, you define a specific CPU, e.g. "R4400". But isn't this is a change in meaning of machine? Put differently, aren't we forced to change the value for machine for pc98 if we want it to work with your paradigm? > > I did not propose anything yet. I'm trying to understand what it > > is you're talking about. At the same time I'm trying to avoid > > defining the problem in terms of the proposed solution so that > > I can validate that there is a problem, whether the solution you > > proposes addresses that problem and see if other solutions exist > > that solve the problem so that we can find the best alternative. > > Okay, but understand I'm doing it this way as opposed to using the > existing mechanism as a kludge, as that is roughly what NetBSD does, > and other systems, and also similar to how we do pc98, and while that > is vaguely meaningful, it ends up being messy like pc98, or like the > system NetBSD has. I want to shift to a different paradigm, as discussed, > and see below. NetBSD has MACHINE_ARCH=mipsel and MACHINE_ARCH=mipseb. They choose to make them different architectures. I understand you are not going to do that, right? > > Good. What is the new paradigm? > > As explained, you have a master port, to the architecture, assume that > it is "mips" ok? That's /sys/mips on FreeBSD. Each architecture port > may have a number of specific platforms it supports. These map to the > definitions of MACHINE_ARCH and MACHINE respectively. An architecture > port then pulls in, based off the "platform" directive, appropriate > options to have MACHINE-specific code. If we assume that is "sgimips" > then it is headers and code in /sys/mips/sgimips. Based on the option > defined in options.mips and files.mips. The build glue sees that our > MACHINE_ARCH directory contains a MACHINE equivalent directory, and it > sets up the <platform> directory, the meta-port headers, which is then > used by the architecture port to tune the meta-data of the port. > > Like Benno put it (probably better than I did) you have an architecture, > and you have MACHINE-specific quirks. Those define a platform. And a > platform is meta-port data to the architecture. > > I feel very good about that definition, does that work for you? Yes. It's what I've been saying all along, except that I use existing variables/keywords and you don't :-) I used MACHINE_ARCH to hold the identification of the master port (mips in this case) and used MACHINE to hold the identification of the platform/implementation (sgimips in this example). So do you, except you map platform onto MACHINE, whereas I map machine onto MACHINE. Now, where I think this went wrong is that you linked this to how it is done with pc98 and how config has it implemented and that is what you don't want. You want a better (directory) structure. My explicit request to not talk in terms of implementation, but instead to keep it abstract failed to prevent that. To be perfectly clear: I think your directory structure makes sense and is better than what we do for pc98. This has on an abstract level nothing toi do with the keyword we use in config. Are we in sync? If we are in sync, we can discuss the ups and down and see what we think works best. Clearly, if we make machine equivalent to MACHINE and we want to have a directory structure as you describe, things need to change. Do we want that, is it doable. One thing is for sure: we don't need both machine and platform in a single kernel config file to do what we want. But is what we want doable with just machine? -- 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?20030129044548.GI1016>