Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jan 2003 19:01:58 -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:  <20030128190158.A15778@FreeBSD.org>
In-Reply-To: <20030129025124.GG1016@athlon.pn.xcllnt.net>; from marcel@xcllnt.net on Tue, Jan 28, 2003 at 06:51:24PM -0800
References:  <20030128151749.A831@FreeBSD.org> <20030128235528.GA844@athlon.pn.xcllnt.net> <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>

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". ]
> > > > We attach lots of meaning to MACHINE.  You keep missing that that
> > > > is NOT the same as the "machine" keyword.
> > > 
> > > And you keep missing that I don't assume that it cannot be made the
> > > same. That's why I ask about meaning and that's why I want things
> > > to be discussed on an abstract level.
> > 
> > OK.  Well, if you make them the same, you are hacking up an existing
> > thing to mean something vastly different, which IMO is ugly and
> > full of repetition, and wholly un-flesible.
> 
> Ok, if making them the same means that we're changing the meaning of
> machine, then clearly you know what the meaning is now. Please
> tell me.

Right now, it says where to get files, options, and Makefile.  In
the paradigm I chose to use, these are all part of the master port,
rather than the meta-port.  Each machine is actually closer to
MACHINE_ARCH in intended meaning from config(8), as it is intended to
be related to the "cpu" directive, e.g. machine defines the architecture,
say, "mips", and to go with it, you define a specific CPU, e.g. "R4400".

> > Unless you propose to
> > create <platform> based on MACHINE in the MACHINE_ARCH != MACHINE
> > case anyway, and use that, there is now even more duplication and
> > obfuscation that must be done to e.g. the headers.
> 
> I did not propose anything yet. I'm trying to understand what it
> is you're talking about. At the same time I'm trying to avoid
> defining the problem in terms of the proposed solution so that
> I can validate that there is a problem, whether the solution you
> proposes addresses that problem and see if other solutions exist
> that solve the problem so that we can find the best alternative.

Okay, but understand I'm doing it this way as opposed to using the
existing mechanism as a kludge, as that is roughly what NetBSD does,
and other systems, and also similar to how we do pc98, and while that
is vaguely meaningful, it ends up being messy like pc98, or like the
system NetBSD has.  I want to shift to a different paradigm, as discussed,
and see below.

> > > >  It is, however, the same
> > > > as the "platform" keyword.
> > > 
> > > You also fail to see that the consequence of adding platform is
> > > beyond the mere recognition of the keyword. Only when the
> > > problem space is 3D, do you need to add a new entity for sure.
> > > If the problem space is 2D, you may be able to solve it with
> > > the existing knobs. Yes, this may mean that you may have to
> > > stop using it for whatever purpose (right or wrong) it's used
> > > now.
> > 
> > I don't want to change the meaning of machine, the two things are
> > orthogonal, but because the name is similar you want to callesce
> > them.
> 
> Again: what does machine mean to you. To what is it othogonal and
> with what do you think I want to coalesce it that has a similar
> name?

It provides something orthogonal to what "platform" does, and I want
it to stay that way, so that things fit below.

> > I want to add a new paradigm of FreeBSD ports, as well as
> > the mechanism to do this, based on what I want to do, and the fact
> > that it makes sense to Benno.
> 
> 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?

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?20030128190158.A15778>