From owner-freebsd-sparc64@FreeBSD.ORG Sat Feb 21 05:07:47 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E65B16A4CE; Sat, 21 Feb 2004 05:07:47 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70C3E43D1D; Sat, 21 Feb 2004 05:07:46 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i1LD7dh23019; Sat, 21 Feb 2004 14:07:39 +0100 (MET) Date: Sat, 21 Feb 2004 14:07:39 +0100 (CET) From: Harti Brandt To: Garance A Drosihn In-Reply-To: Message-ID: <20040221140438.M87450@beagle.fokus.fraunhofer.de> References: <40306CE7.6080104@mindspring.com> <20040216193108.GE12181@seekingfire.com> <20040217040616.GL12181@seekingfire.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@freebsd.org cc: ru@freebsd.org Subject: Re: Back to the Future - 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2004 13:07:47 -0000 On Fri, 20 Feb 2004, Garance A Drosihn wrote: GAD>At 7:56 PM -0800 2/19/04, Marcel Moolenaar wrote: GAD>>On Thu, Feb 19, 2004, Garance A Drosihn wrote: GAD>> > GAD>>> My basic plan is to commit these three files to /usr/src on GAD>> > March 1st. ... Then, at some later date, we'd commit the GAD>> > change to /usr/src/sys/sparc64/include/_types.h which makes GAD>> > the switch, and add an entry in /usr/src/UPDATING ... GAD>> > GAD>>> Does this seem reasonable? GAD>> GAD>>Is there a way we can avoid footshooting? GAD>> GAD>>For example: check if /usr/include/machine/_types.h is equal to GAD>>the one in the source tree and disallow installworld without GAD>>some special define if they're not. The scripts use the define GAD>>to circumvent the anti-footshooting measure. Something along GAD>>those lines... GAD> GAD>I would really like to have something like this, but I doubt I GAD>have the time to make it happen. I am not quite sure how it GAD>would be hooked up to the buildworld/installworld process, either. GAD>Maybe Ruslan could help me out there. GAD> GAD>In thinking about this, I think the simplest solution would be GAD>some program which is compiled & run at buildworld time, and GAD>which is also run at installworld time. We would want it to GAD>run it as early as possible in the processing of those targets. GAD> GAD>I *think* what would work is something like: GAD>In /etc/make.conf, users would define: GAD> GAD>SPARCWORLD_TIMET=32bit or SPARCWORLD_TIMET=64bit GAD> GAD>If neither is defined, than 32-bit is assumed. That would look like an option to build either way and I think we shouldn't have such an option that allows 32bit time_t's. This will require to ship to sets of packages and will give as a lot of bug reports because of mismatched packages and kernels. GAD>You then have a program in buildworld which simply looks at the GAD>length of time_t that it finds at compile-time, and prints out GAD>a single-line which says '64bit' or '32bit'. GAD> GAD>Then, in both buildworld and installworld (and maybe buildkernel GAD>and installkernel), you add logic which says something vaguely GAD>like: GAD> GAD> SPARCWORLD_TIMET?=32bit GAD> FOUND_TIMET="`${.OBJDIR}/something/check_program`" GAD> if [ "${SPARCWORLD_TIMET}" != "`check_program`" ] then GAD> echo "You are building a $FOUND_TIMET system, but you seem" GAD> echo "to expect to build a $SPARCWORLD_TIMET system. You" GAD> echo "must either modify /etc/make.conf to add:" GAD> echo " SPARCWORLD_TIMET=$FOUND_TIMET" GAD> echo "or edit /usr/src/sys/sparc64/include/_types.h to" GAD> echo "change the type of __time_t to be " GAD> exit 1 GAD> fi GAD> GAD>If I've done this right, then people will be forced to add GAD>SPARCWORLD_TIMET=64bit to their /etc/make.conf when they GAD>make the switch to 64-bit time_t's. Once they do that, though, GAD>they can be reasonably sure they will never mistakenly build or GAD>install a 32-bit time_t system over an already-64-bit system. GAD> GAD>I am certain that there are some details I have overlooked, but I GAD>really don't have the time to think it through right now. GAD> GAD> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org