Date: Tue, 28 Jan 2003 21:37:16 -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: <20030128213716.A24203@FreeBSD.org> In-Reply-To: <20030129051853.GJ1016@athlon.pn.xcllnt.net>; from marcel@xcllnt.net on Tue, Jan 28, 2003 at 09:18:53PM -0800 References: <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> <20030129051853.GJ1016@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". ]
> 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.
I'm not talking only about MACHINE_ARCH, but also where the MD files
and so on are. If we moved to sys/ARCH/conf/files and so on, I'd
be more supportive of such an approach. And if we made pc98 not
dumb in this regard (with consent of their maintainers).
> > 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,
That sort of keyword is even more convoluted than platform.
> 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.
MACHINE is a cpp define and (relatedly) is defined by make(1),
it isn't a config file element. Why do they have to be related
just because they by coincidence have the same name?
> This is illogical. The machine keyword basicly controls
> source layout and has nothing to do with the machine you're
> building for. Again, illogical.
Yes it does, in a traditional meaning of machine. "This is being
built for the MIPS machine, with support for the sgimips platform."
Or "This is being built for the VAX [machine]."
> 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).
My case affects nothing, therefore, since yours is good for only
affecting one, mine is better for only affecting none, and for working
right in every case. You don't like my choice of how, that's fine,
you don't have to maintain a port which uses it. All the more reason
for it to not be one that is even used by you at all.
I've made a note that you don't think my way is optimal. I do, and
that's that, at this point. No black magic, no convoluted config
files, etc. Go deal with the ODE config and Mach's configuration
files, I have. Or NetBSD's. Or OpenBSD's. At this point, I am
convinced that the platform keyword is the least offensive and most
productive way of doing all of this, and so on, being someone who
has worked with more backwards methods, and being the person who
had to deal with this first, and came up with something that suits
the two groups who need it most (the pc98 mistake is probably near
impossible to correct, due to the historical nature), MIPS, and
PowerPC.
If you can convince the PowerPC folks to go with what you suggest,
then I'll be glad to also push for files, etc., to be in the proper
place, as the significance of the configuration file's contents
becoems even less important (except for the option of having a
directive point to the meta-port, which is horrid, and which I'd
really dislike seeing go in as a solution to part of these issues).
Or I suppose, since you seem to have more of a desire to re-spend
the time I spent planning this out, you could take it up with the
technical review board. I'm feeling far too drained from this
sort of discussion, I've done the work, and made sure it works (and
discussed it with Peter (the config(8) maintainer) a long time
ago), and at this point I want to commit it or give up, and use
it for my purposes.
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?20030128213716.A24203>