Date: 29 Jan 2003 19:19:38 +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: <1043828377.648.67.camel@localhost> In-Reply-To: <20030129074647.GD1715@athlon.pn.xcllnt.net> References: <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> <1043819769.648.52.camel@localhost> <20030129062558.GB1715@athlon.pn.xcllnt.net> <1043821970.648.60.camel@localhost> <20030129074647.GD1715@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-lBHUXD3yjIwVZY+r0OC0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote:
> On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote:
> > >=20
> > > Agreed. There's an advantage there, but see also my reply to
> > > Juli about the use of "machine" to mean MACHINE_ARCH and the
> > > use of "platform" to mean MACHINE. This I don't find appealing.
> >=20
> > I can see your point here, but if needed I'd rather see them renamed to
> > MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHIN=
E
> > and MACHINE_ARCH are confusingly similar.
>=20
> I'm not sure I understand you. I don't mind the capitalization,
> just that we have MACHINE_ARCH and MACHINE defined on the hand
> and "machine" and "platform" on the other. If you would ask a
> person how they should be related, I can imagine that the
> logical should would be to relate "machine" to MACHINE and
> "platform" to MACHINE_ARCH. Which is opposite to what Juli
> proposed. That's the unappealing part. Not a biggy, but
> something that's better avoided now than fixed later.
In that case I'm mostly in agreement. Avoiding confusion is a Good
Thing(tm).
[snip]
> > > Agreed. We should not do the same, but instead of saying that we
> > > do mips and powerpc different, I think we should say that mips and
> > > powerpc do it the normal way and pc98 does it differently. I like
> > > to use an extra keyword for the weird case (pc98) and not the normal
> > > (common) case. See also above, this is looking at it from a point
> > > of view we'll going to have in the future, not a point of view
> > > we all have now.
> >=20
> > Ok, so are you saying here that Juli's patch is ok but we need to look
> > at how we deal with pc98?
>=20
> I would not introduce a <platform/foo.h>, but rather
> <machine/${variant}/foo.h>. The reason for this is that the
> /usr/include/platform directory is only needed on powerpc and mips,
> which seems to indicate that it should be under <machine>. Also,
> the use of machine/${variant} allows us to install the headers for
> all variants, which may improve cross-building. Note that I haven't
> tried it on for size, so I'm not fixated on it. I was hoping this
> would fall out of the discussion.
>=20
> You see how the current approach affects other architectures if you
> look at the diff for src/sys/conf/kmod.mk. All architectures,
> including those that don't have multiple variants will have a link
> added that mirrors the machine link. I find that aestheticly
> displeasing. If you have the variants under <machine>, you don't
> have to create more links.
>=20
> The change to src/include/Makefile also seems to have a bug in
> that it depends in /usr/include/platform to be created by
> mtree, but I don't see and diff for that. Adding platform to
> BSD.include.dist means that every architecture gets the
> directory. Otherwise it has to be created by hand for those
> platforms that have it.
>=20
> The same happens in config(8) where we create a platform link
> in all cases, not just for powerpc and mips.
Ok, the nice side to having platform/foo.h is that (to go back to the
endian example) you can have machine/endian.h including
platform/endian.h and not having to be a mess like:
#if defined(POWERMAC)
#include <machine/powermac/endian.h>
#elsif defined(LITTLE_ENDIAN_ARCH)
#include <machine/little_endian_arch/endian.h>
#elsif
...
#endif
It doesn't have to be /usr/include/platform, it could be
/usr/include/machine/platform for instance, but it'd be nice for it to
have a constant name.
> > Or are you saying that you would prefer to change how the machine =20
> > directive works in config(8) and introduce a new "non-standard"
> > directive for pc98?
>=20
> That was the thought I was playing with.
Hmm. Juli, what do you think of this?
We could perhaps introduce "platform" and make it mutually exclusive
with "machine", and that way if the config file has a "machine"
directive we get the old behaviour and only invoke the new behaviour
when we have a "platform" directive. Then we can start transitioning
over to it as needed. This is pretty much a no-op on sparc64, ia64 and
alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it
later on. Perhaps this could be a target for 6.0.
> > If the former, I agree totally. If the latter, I'm not so sure. I'd
> > rather see the directive be "platform" as that is a much more accurate
> > name for it IMO. If this means we kill off the machine directive, then
> > that may be how it works.
>=20
> I don't have a problem with the name platform, although I avoid it
> for now to avoid confusion.
*nod* Fair enough.
--=20
Benno Rice <benno@FreeBSD.org>
--=-lBHUXD3yjIwVZY+r0OC0
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+N46ZXjRwWofFmQkRAh6XAJ9j8M5me7FhBSaxTc9Tql7b8oe34ACdFgH7
aL0N2PN/X8dcEkHX7/LAz6Y=
=a4X7
-----END PGP SIGNATURE-----
--=-lBHUXD3yjIwVZY+r0OC0--
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?1043828377.648.67.camel>