From owner-freebsd-current Tue Jan 28 21:18:58 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 C7E7437B401; Tue, 28 Jan 2003 21:18:55 -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 7717643F9B; Tue, 28 Jan 2003 21:18:54 -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 h0T5IsMW067910; Tue, 28 Jan 2003 21:18:54 -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 h0T5IrKm001668; Tue, 28 Jan 2003 21:18:53 -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 h0T5Irb8001667; Tue, 28 Jan 2003 21:18:53 -0800 (PST) Date: Tue, 28 Jan 2003 21:18:53 -0800 From: Marcel Moolenaar To: Juli Mallett Cc: current@FreeBSD.ORG Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030129051853.GJ1016@athlon.pn.xcllnt.net> References: <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> <20030128205737.A22274@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030128205737.A22274@FreeBSD.org> 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 Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote: > > 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 > %%% No, I see MACHINE_ARCH implied by where you run config. This seems strange and I'm not completely sure it's a good thing, but MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and defining the architecture in the kernel config file only allows a limited freedom; namely the freedom to have the config file outside the source tree. It basicly only defines a directory, nothing else. See also below for pc98. Thus, MACHINE_ARCH is not specified and "machine" holds the implementation (ie platform). This is exactly what we have now, so you don't change the meaning. > 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. Correct. I either want pc98 transformed or if that's not possible or feasible, a keyword "root", "tree", "directory" or " "nonstandardlocation" to tell config(8) that the (sub-)port is not where we normally have it. We then create a new keyword, but it explcitly means a location, a path. The introduction of platform is more confusing. First of all it maps to MACHINE, while we have the machine keyword mapping to something else. This is illogical. The machine keyword basicly controls source layout and has nothing to do with the machine you're building for. Again, illogical. So, I'm not opposed to having a new variable if it's too hard to do it without, but I think there's a more logical/optimal scheme of naming and attaching meaning that does not affect the common case (it only affects pc98). > 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. Ok, what are those exactly. -- 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