Date: Tue, 6 Jan 2004 10:17:21 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-sparc64@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 Message-ID: <20040106095942.O66232@beagle.fokus.fraunhofer.de> In-Reply-To: <p06020426bc1fe1f269d8@[128.113.24.47]> References: <200312212239.38557.craig@xfoil.gank.org> <p0602040fbc0cf0dddf9e@[128.113.24.47]> <p06020426bc1fe1f269d8@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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>> 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>> 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> 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>time_t. GAD> GAD>So, all I need to change is the line: GAD> typedef __int32_t __time_t; GAD> GAD>in /usr/src/sys/sparc64/include/_types.h GAD>and the line: GAD> long tv_sec; /* seconds (XXX should be time_t) */ GAD> GAD>in /usr/src/sys/sys/_timeval.h GAD> GAD>Most the other definitions of tv_sec that I found are GAD>already using time_t. Btw, I noticed: GAD>sys/netinet/ip_fw.h: GAD> u_int32_t timestamp; /* tv_sec of last match*/ GAD>sys/netinet6/ip6_fw.h: GAD> long timestamp; /* timestamp (tv_sec) of last match */ GAD> GAD>but I haven't looked at the code to see how much we care about GAD>those two references. GAD> 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 -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040106095942.O66232>