From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 15 11:56:47 2003 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 4048916A4B3; Wed, 15 Oct 2003 11:56:47 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3593A43FBF; Wed, 15 Oct 2003 11:56:46 -0700 (PDT) (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.10/8.12.9) with ESMTP id h9FIueF1024985; Wed, 15 Oct 2003 14:56:41 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031015075111.GA52914@rot13.obsecurity.org> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> <20031015075111.GA52914@rot13.obsecurity.org> Date: Wed, 15 Oct 2003 14:56:39 -0400 To: Kris Kennaway , Marcel Moolenaar From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: standards@freebsd.org cc: Bruce Evans cc: sparc64@freebsd.org Subject: Re: 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, 15 Oct 2003 18:56:47 -0000 At 12:51 AM -0700 10/15/03, Kris Kennaway wrote: >On Wed, Oct 15, 2003, Marcel Moolenaar wrote: > > > Yes. The MI code is already done and there's not much MD > > code that is expected to break. It's mostly the structures > > that change. ... > >I'd much prefer we get it over with now before sparc64 gets >widely deployed. It's going to be much more painful once >there's an installed user base running production 5.x-STABLE >systems. I agree it would be better if we had 64-bit time_t's for 5.x-STABLE. I would really really like to see that. However, we are hoping to make 5.x turn into 5.x-stable with a release of 5.2 in December. We have plenty of other things which are already in the TO-DO list for 5.2, and I think it's just too late in the cycle to toss this change into the mix. In a different message, Marcel Moolenaar wrote: >BTW: time_t on ia64 is already 64 bit. Our current lineup is: alpha: typedef __int32_t __time_t; arm: typedef __int32_t __time_t; i386: typedef __int32_t __time_t; powerpc: typedef __int32_t __time_t; sparc64: typedef __int32_t __time_t; amd64: typedef __int64_t __time_t; ia64: typedef __int64_t __time_t; I could see moving powerpc to 64-bit, since that is still very much work in progress. If the powerpc port is broken by this change, we would not have to delay 5.2 for it. If there is some unpleasant fallout in changing time_t for sparc64, then we will have to delay 5.2 until all of those side-effects are sorted out. Either that, or delay "5.x-stable" to 5.3-release. And if we delay 5.x-stable to 5.3-release, then we'll find ourselves two months before 5.3-release and saying "We really should make change now, instead of waiting for 6.x-stable", and it'll be the same thing all over again. There is *always* a major change that we'd rather get done "now" instead of waiting for the next major release. This is particularly true as the time between major releases gets stretched to four or more years. So, I'd love to have it, but I think we should wait for 6.0. IMO. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu