Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Jan 2003 02:04:11 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Benno Rice <benno@FreeBSD.org>
Cc:        Juli Mallett <jmallett@FreeBSD.org>, current@FreeBSD.org
Subject:   Re: Patch to teach config(8) about "platforms".
Message-ID:  <20030129100411.GA3272@dhcp01.pn.xcllnt.net>
In-Reply-To: <1043828377.648.67.camel@localhost>
References:  <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> <1043828377.648.67.camel@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 29, 2003 at 07:19:38PM +1100, Benno Rice wrote:
> 
> > 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.

Agreed. A link is better.

> > > Or are you saying that you would prefer to change how the machine  
> > > directive works in config(8) and introduce a new "non-standard"
> > > directive for pc98?
> > 
> > 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.

What if an architecture doesn't have different platforms. Do we
want to give a platform name that matches the architecture or
do we make platform optional? I think I prefer it to be optional.
This could mean we have a kernel config file that has no machine
and not platform keyword.

I've been thinking about the implicit selection of the architecture
based on where the config file lives. We currently restrict where
config(8) can be run from and don't really have a nice way of
dealing with the case where SYSTEM_NAME is actually a path. This
basicly means that we must run config(8) from /sys/$ARCH/conf.
This makes the implicit selection of the architecture logical,
even or especially if we want to remove the restriction of where we
have the kernel config file and/or where we run the config(8)
utility from later. We can always add the necessary options and
keywords to deal with the added flexibility, including making the
architecture explicit. In that case it would work the same on all
architectures without any weird interferences of having multiple
platforms.

Thoughts?

-- 
 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?20030129100411.GA3272>