From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 6 21:08:21 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 9FDD116A4CE; Tue, 6 Jan 2004 21:08:21 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 060D343D45; Tue, 6 Jan 2004 21:08:20 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i0758FLJ027335; Wed, 7 Jan 2004 00:08:19 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040106182824.GA42422@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> Date: Wed, 7 Jan 2004 00:08:13 -0500 To: freebsd-sparc64@freebsd.org, harti@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Gearing up for 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: Wed, 07 Jan 2004 05:08:21 -0000 At 10:28 AM -0800 1/6/04, David O'Brien wrote: >On Tue, Jan 06, 2004, Harti Brandt wrote: > > That's just what I did. The real problem is the upgrade > > procedure and whether we will force people to recompile > > everything (and not provide a compatibility library). > >I think we can have a 'Flag Day' and not deal with a compat lib. That's what I was going to shoot for. While I did not get a lot of reaction to my previous messages in November, it seemed that most people thought we should just make the change. > > The only problem with the upgrade procedure I had was with > > tic, that for some reason got into an endless loop when > > running on the wrong kernel. > >We would need a fool-proof procedure for going from say a >5.0-R install to post 64-bit time_t. How flexible should we be? My first thought is to tell people: 1) upgrade to RELENG_5_2 2) *after* you know that upgrade worked, then run a patch file (which will already be in /usr/src?), which will modify the appropriate files needed for this change. 3) rebuild after making just that one change. No cvsup. 3a) ...details to be filled in... 3b) ...blah blah, rebuild key ports, etc etc... 4) change your cvsup files to tag=. Or we could do a more flexible version, combining a -Define in CFLAGS (set in /etc/make.conf), along with some extra magic when installing the include files during 'make installworld'. Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64. The remaining steps would be the same, but users could flip the switch at whatever time they wanted, instead of being forced to upgrade to RELENG_5_2. I think users should still do a "double install", where they first have to get thru a successful install at one point, and then modify the setting in /etc/make.conf and immediately do a second install. I think it is a good idea to have everyone upgrade to RELENG_5_2 first anyway, because we already have quite a lot of changes between 5.0-Release and RELENG_5_2. However, I'd be willing to work towards the second idea if other sparc users really want the more flexible option. I realize I skipped over the important details in "step 3", but I hope to start filling those in later this week or the weekend. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu