Gearing up for 64-bit time_t on sparc64
brandt at fokus.fraunhofer.de
Tue Jan 6 01:17:28 PST 2004
On Mon, 5 Jan 2004, Garance A Drosihn wrote:
GAD>In the thread on
GAD> Re: An experiment: 64-bit time_t on IA-32 (5.2-RC)
GAD>David O'Brien wrote:
GAD>>On Mon, Dec 22, 2003, Garance A Drosihn wrote:
GAD>> > Note that there it is likely we will switch sparc64 to a
GAD>>> 64-bit time_t before 5.3 is released. We talked about making
GAD>>> that change sometime in January, once we would be sure that
GAD>>> 5.2-release was settled.
GAD>>On Tue, Dec 23, 2003, Harti Brandt wrote:
GAD>> > time_t is a long on Solaris and hence 64bit (when compiling
GAD>> > in 64-bit mode). Compatibility (with Solaris and Posix)
GAD>> > requires time_t to be 64-bit and tv_sec to be a time_t.
GAD>> > I'm running with a 64-bit time_t for two months now
GAD>> > without problems.
GAD>>Before the tree starts to get disruptive and unstable on the
GAD>>push to 5.3; maybe this is a good time to make the switch to
GAD>>64-bit time_t for sparc64.
GAD>I think this is a good idea. I just finished a clean install of
GAD>5.2-RC2 on my ultra-10, and I'm building a few of my favorite
GAD>ports on that. I'll then duplicate that install to alternate
GAD>partitions, and see what happens when updating that to a 64-bit
GAD>So, all I need to change is the line:
GAD> typedef __int32_t __time_t;
GAD>and the line:
GAD> long tv_sec; /* seconds (XXX should be time_t) */
GAD>Most the other definitions of tv_sec that I found are
GAD>already using time_t. Btw, I noticed:
GAD> u_int32_t timestamp; /* tv_sec of last match*/
GAD> long timestamp; /* timestamp (tv_sec) of last match */
GAD>but I haven't looked at the code to see how much we care about
GAD>those two references.
GAD>Anything else, Harti?
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
Providing a compat library would require a library version bump, correct?
We are already at 5 so we can't do this. Given that there is no stable,
we can argument that's how current is and go with that (and that's the
reason for doing the change now).
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.
brandt at fokus.fraunhofer.de, harti at freebsd.org
More information about the freebsd-sparc64