From owner-freebsd-current Tue Jan 28 23:46:52 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A281B37B401; Tue, 28 Jan 2003 23:46:49 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E5543F3F; Tue, 28 Jan 2003 23:46:47 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0T7klMW068455; Tue, 28 Jan 2003 23:46:47 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0T7klKm002037; Tue, 28 Jan 2003 23:46:47 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0T7klZX002036; Tue, 28 Jan 2003 23:46:47 -0800 (PST) Date: Tue, 28 Jan 2003 23:46:47 -0800 From: Marcel Moolenaar To: Benno Rice Cc: Juli Mallett , current@FreeBSD.org Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030129074647.GD1715@athlon.pn.xcllnt.net> References: <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> <20030128205737.A22274@FreeBSD.org> <20030129051853.GJ1016@athlon.pn.xcllnt.net> <1043819769.648.52.camel@localhost> <20030129062558.GB1715@athlon.pn.xcllnt.net> <1043821970.648.60.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1043821970.648.60.camel@localhost> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote: > > > > Agreed. There's an advantage there, but see also my reply to > > Juli about the use of "machine" to mean MACHINE_ARCH and the > > use of "platform" to mean MACHINE. This I don't find appealing. > > I can see your point here, but if needed I'd rather see them renamed to > MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE > and MACHINE_ARCH are confusingly similar. I'm not sure I understand you. I don't mind the capitalization, just that we have MACHINE_ARCH and MACHINE defined on the hand and "machine" and "platform" on the other. If you would ask a person how they should be related, I can imagine that the logical should would be to relate "machine" to MACHINE and "platform" to MACHINE_ARCH. Which is opposite to what Juli proposed. That's the unappealing part. Not a biggy, but something that's better avoided now than fixed later. > > > Juli's patches don't touch the common case. > > > > We have 3 architectures that have multiple machines or platforms > > (mips, powerpc and i386). Setting "platform" for mips and powerpc > > and not i386 means that you're setting it for the common case, > > because you could have "nonstandardlocation" defined for only pc98. > > Again, this is just looking at it from a different point of view, > > but a point of view we all have in a year from now when we moved > > there. > > True. This is fixable though. Yes. This would be enough to not worry about it now and I would be fine with it. > > Agreed. We should not do the same, but instead of saying that we > > do mips and powerpc different, I think we should say that mips and > > powerpc do it the normal way and pc98 does it differently. I like > > to use an extra keyword for the weird case (pc98) and not the normal > > (common) case. See also above, this is looking at it from a point > > of view we'll going to have in the future, not a point of view > > we all have now. > > Ok, so are you saying here that Juli's patch is ok but we need to look > at how we deal with pc98? I would not introduce a , but rather . The reason for this is that the /usr/include/platform directory is only needed on powerpc and mips, which seems to indicate that it should be under . Also, the use of machine/${variant} allows us to install the headers for all variants, which may improve cross-building. Note that I haven't tried it on for size, so I'm not fixated on it. I was hoping this would fall out of the discussion. You see how the current approach affects other architectures if you look at the diff for src/sys/conf/kmod.mk. All architectures, including those that don't have multiple variants will have a link added that mirrors the machine link. I find that aestheticly displeasing. If you have the variants under , you don't have to create more links. The change to src/include/Makefile also seems to have a bug in that it depends in /usr/include/platform to be created by mtree, but I don't see and diff for that. Adding platform to BSD.include.dist means that every architecture gets the directory. Otherwise it has to be created by hand for those platforms that have it. The same happens in config(8) where we create a platform link in all cases, not just for powerpc and mips. > Or are you saying that you would prefer to change how the machine > directive works in config(8) and introduce a new "non-standard" > directive for pc98? That was the thought I was playing with. > If the former, I agree totally. If the latter, I'm not so sure. I'd > rather see the directive be "platform" as that is a much more accurate > name for it IMO. If this means we kill off the machine directive, then > that may be how it works. I don't have a problem with the name platform, although I avoid it for now to avoid confusion. -- 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