Date: Tue, 28 Jan 2003 20:57:38 -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: <20030128205737.A22274@FreeBSD.org> In-Reply-To: <20030129044548.GI1016@athlon.pn.xcllnt.net>; from marcel@xcllnt.net on Tue, Jan 28, 2003 at 08:45:48PM -0800 References: <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> <20030129044548.GI1016@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". ] > > > 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? Yes, you are following me. But also, you mention that "machine" as implemented means what I said it means, but there is other precident for using it as I say. For example, BSD/OS uses "machine sparc" and "options SUN4M". NetBSD uses machine in a way more similar to what you want, but like "machine sgimips mips" for example. What we want... Could be done with machine, if we allow there to be no files.XXX for a given "machine XXX" and so on, but I think this is less clear. How would you propose to write the following: %%% machine mips platform sgimips %%% Would you write it as: %%% machine mips sgimips %%% If so, how do you know which is MACHINE and which is MACHINE_ARCH? How do you accurately get a <platform> include directory? Certainly we don't want to make i386 do this: %%% architecture i386 machine i386 %%% Because that would be backwards... But an addition of something like platform would allow it to be orthogonal to existing structure, it would not mandate its use, of course... And so on. There's more at stake than just what we need, it also has to make sense when we don't need it, and so on. The above two things I have suggested break in dumb ways... If you just figure out the MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could define MACHINE based on the machine directive, and as such, on i386 and sparc64 and ... it would do the right thing, and it would allow the MIPS stuff to be done, but it breaks the existing pc98 stuff, because it resides in /sys/$MACHINE. I really think we need platform, and I really think it needs to come in as part of new infrastructure, as it provides something totally new which breaks in interesting ways if you don't make it optional and cleanly seperated as I've tried to do. Again, this is based off experience with a number of build systems, and the needs of PowerPC and MIPS, and also is something I run on my laptop, which is i386. It stays out of the way and only affects those explicit consumers of it. The more we discuss making "machine" act like platform, the more concerns that come to my head for that, and the more platform seems right to me. 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?20030128205737.A22274>