Date: Tue, 28 Jan 2003 21:18:53 -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: <20030129051853.GJ1016@athlon.pn.xcllnt.net> In-Reply-To: <20030128205737.A22274@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030129051853.GJ1016>