From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 20 14:13:14 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 2F94C16A4CE; Fri, 20 Feb 2004 14:13:14 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCD7E43D3F; Fri, 20 Feb 2004 14:13:13 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i1KMDCm1021767; Fri, 20 Feb 2004 17:13:13 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040220035635.GA69900@dhcp01.pn.xcllnt.net> References: <40306CE7.6080104@mindspring.com> <20040216193108.GE12181@seekingfire.com> <20040217040616.GL12181@seekingfire.com> <20040219143838.GL68388@seekingfire.com> <20040219204008.GB3545@electra.cse.Buffalo.EDU> <20040219205750.GC3545@electra.cse.Buffalo.EDU> <20040220035635.GA69900@dhcp01.pn.xcllnt.net> Date: Fri, 20 Feb 2004 17:13:11 -0500 To: Marcel Moolenaar From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: ru@freebsd.org cc: sparc64@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: Fri, 20 Feb 2004 22:13:14 -0000 At 7:56 PM -0800 2/19/04, Marcel Moolenaar wrote: >On Thu, Feb 19, 2004, Garance A Drosihn wrote: > > >> My basic plan is to commit these three files to /usr/src on > > March 1st. ... Then, at some later date, we'd commit the > > change to /usr/src/sys/sparc64/include/_types.h which makes > > the switch, and add an entry in /usr/src/UPDATING ... > > >> Does this seem reasonable? > >Is there a way we can avoid footshooting? > >For example: check if /usr/include/machine/_types.h is equal to >the one in the source tree and disallow installworld without >some special define if they're not. The scripts use the define >to circumvent the anti-footshooting measure. Something along >those lines... I would really like to have something like this, but I doubt I have the time to make it happen. I am not quite sure how it would be hooked up to the buildworld/installworld process, either. Maybe Ruslan could help me out there. In thinking about this, I think the simplest solution would be some program which is compiled & run at buildworld time, and which is also run at installworld time. We would want it to run it as early as possible in the processing of those targets. I *think* what would work is something like: In /etc/make.conf, users would define: SPARCWORLD_TIMET=32bit or SPARCWORLD_TIMET=64bit If neither is defined, than 32-bit is assumed. You then have a program in buildworld which simply looks at the length of time_t that it finds at compile-time, and prints out a single-line which says '64bit' or '32bit'. Then, in both buildworld and installworld (and maybe buildkernel and installkernel), you add logic which says something vaguely like: SPARCWORLD_TIMET?=32bit FOUND_TIMET="`${.OBJDIR}/something/check_program`" if [ "${SPARCWORLD_TIMET}" != "`check_program`" ] then echo "You are building a $FOUND_TIMET system, but you seem" echo "to expect to build a $SPARCWORLD_TIMET system. You" echo "must either modify /etc/make.conf to add:" echo " SPARCWORLD_TIMET=$FOUND_TIMET" echo "or edit /usr/src/sys/sparc64/include/_types.h to" echo "change the type of __time_t to be " exit 1 fi If I've done this right, then people will be forced to add SPARCWORLD_TIMET=64bit to their /etc/make.conf when they make the switch to 64-bit time_t's. Once they do that, though, they can be reasonably sure they will never mistakenly build or install a 32-bit time_t system over an already-64-bit system. I am certain that there are some details I have overlooked, but I really don't have the time to think it through right now. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu