time_t on sparc64
Garance A Drosihn
drosih at rpi.edu
Wed Oct 15 11:56:47 PDT 2003
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
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.
Garance Alistair Drosehn = gad at gilead.netel.rpi.edu
Senior Systems Programmer or gad at freebsd.org
Rensselaer Polytechnic Institute or drosih at rpi.edu
More information about the freebsd-standards