From owner-freebsd-current Wed Jan 29 2: 4:15 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3977337B401; Wed, 29 Jan 2003 02:04:13 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28CB443F43; Wed, 29 Jan 2003 02:04:12 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0TA4BMW068961; Wed, 29 Jan 2003 02:04:11 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0TA4BVL003545; Wed, 29 Jan 2003 02:04:11 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0TA4BCH003544; Wed, 29 Jan 2003 02:04:11 -0800 (PST) (envelope-from marcel) Date: Wed, 29 Jan 2003 02:04:11 -0800 From: Marcel Moolenaar To: Benno Rice Cc: Juli Mallett , current@FreeBSD.org Subject: Re: Patch to teach config(8) about "platforms". Message-ID: <20030129100411.GA3272@dhcp01.pn.xcllnt.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1043828377.648.67.camel@localhost> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 > #elsif defined(LITTLE_ENDIAN_ARCH) > #include > #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