Gearing up for 64-bit time_t on sparc64

Harti Brandt brandt at
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>in /usr/src/sys/sparc64/include/_types.h
GAD>and the line:
GAD>    long		tv_sec;		/* seconds (XXX should be time_t) */
GAD>in /usr/src/sys/sys/_timeval.h
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
compatibility library).

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.

harti brandt,
brandt at, harti at

More information about the freebsd-sparc64 mailing list