Date: Wed, 15 Oct 2003 14:56:39 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Kris Kennaway <kris@obsecurity.org>, Marcel Moolenaar <marcel@xcllnt.net> Cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 Message-ID: <p06002002bbb33b2002dd@[128.113.24.47]> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <other> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06002002bbb33b2002dd>