Date: 29 Jan 2003 16:56:10 +1100 From: Benno Rice <benno@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Juli Mallett <jmallett@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <1043819769.648.52.camel@localhost> In-Reply-To: <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> <20030129051853.GJ1016@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-gRS7zeE8JED3L4dACoxn
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Wed, 2003-01-29 at 16:18, Marcel Moolenaar wrote:
> On Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote:
> >=20
> > 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:
> >=20
> > %%%
> > machine mips
> > platform sgimips
> > %%%
> >=20
> > Would you write it as:
> >=20
> > %%%
> > machine mips sgimips
> > %%%
>=20
> 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.
>=20
> 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.
This is just confusing. Having just played with this, if I specify
machine i386 while in the sys/powerpc/conf directory, I end up with an
unbuildable configuration as it sucks in the i386 Makefile but assumes
that it's arch-specific files are in ../../include.
This means that we would need to use:
machine powermac
in the config file while being in the powerpc directory, and then have a
sys/conf/*.powermac (along with all the other ones). This to me is
backwards.
If we follow Juli's suggestion, we have:
machine powerpc
platform powermac
and this uses the standard sys/conf/*.powerpc and simply pick up a set
of platform-dependant includes from sys/powerpc/powermac. The options
logic handles the rest as we already have lines in
sys/conf/files.powerpc like:
powerpc/powermac/uninorth.c optional powermac pci
powerpc/powermac/macio.c optional powermac pci
powerpc/powermac/ata_macio.c optional powermac ata
Then when we head off to implement a little-endian powerpc platform we
can use:
machine powerpc
platform little-endian-platform
and it'll grab it's includes out of sys/powerpc/little-endian-platform
and we can do the same sort of files.powerpc magic as above.
Juli's form is also more explicit, which I find appealing.
> > 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.
>=20
> 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.
>=20
> 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).
Juli's patches don't touch the common case. If you don't specify a
platform then you don't get that extra logic. Easy. I agree that
moving pc98 over to whatever system we want to use is a good idea, but
for the moment I'd be happy with not forcing mips and powerpc down the
same road as pc98 which I see as being overly painful and confusing.
--=20
Benno Rice <benno@FreeBSD.org>
--=-gRS7zeE8JED3L4dACoxn
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQA+N2z5XjRwWofFmQkRAq8nAJ4wgXlyPYqZj3AmVe7OFhrujQFdSgCdEb/W
KXovddFzzGP9rVnj+J5IkF4=
=auGY
-----END PGP SIGNATURE-----
--=-gRS7zeE8JED3L4dACoxn--
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?1043819769.648.52.camel>