From owner-freebsd-sparc64@FreeBSD.ORG Sat Feb 21 10:59:20 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 263C416A4CE; Sat, 21 Feb 2004 10:59:20 -0800 (PST) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D40FA43D2D; Sat, 21 Feb 2004 10:59:19 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i1LIx8HQ031511; Sat, 21 Feb 2004 13:59:08 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040221140438.M87450@beagle.fokus.fraunhofer.de> 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> <20040221140438.M87450@beagle.fokus.fraunhofer.de> Date: Sat, 21 Feb 2004 13:59:06 -0500 To: Harti Brandt From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) 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 18:59:20 -0000 At 2:07 PM +0100 2/21/04, Harti Brandt wrote: >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. Well, I was just giving a basic idea of something we could do, I did not mean to imply this is all we would ever do. This would just be a transition aid, and like all transition aids it would eventually disappear. Initially, I think we DO want to allow 32-bit builds. But then, after a week or two, we would simply change the script to say: "I'm sorry dave, but I can't let you do 32-bit builds anymore". Why do we want to allow 32-bit builds? Because the instructions say: First do a 32-bit build. Install it. Once you know that that installation is working, Change _types.h, do a 64-bit build, and install that. >GAD> I am certain that there are some details I have overlooked, but >GAD> I really don't have the time to think it through right now. I probably should have *started* my message by emphasizing this part more strongly. I think the low-level details are workable, but some developer would have to sit down and think them out. That is what I do not have the time to do. Also keep in mind that whatever we do for 5.x-current, we will also have users who are sticking on 5.2.1-security until 5.2- release comes out. It would be nice if they also had a way to make a smooth transition, without the risk of shooting their foot off... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu