An experiment: 64-bit time_t on IA-32 (5.2-RC)

There was a recent discussion of 29-bit time values on slashdot, which turned 
into a discussion of 32-bit values and the (mosty) well-known 2038 *NIX 
'doomsday'.  This piqued my curiosity so I decided to see how hard it would 
be to get the i386 version of FreeBSD to use int64_t for time_t.

The initial compile went off without a hitch.  This is no doubt due to hard 
work by the people working on the ia64, amd64, etc. ports where time_t is 
64-bits by default.  A side note, I noticed that the alpha and sparc64 ports 
seem to be using 32-bit time_t, which surprised me.  Some googling showed 
that sparc64 is thinking about it but didn't want to rock the boat before 
5.3.

The installworld was a bit tricky, due to small problems like init segfaulting 
on the new kernel and the cross-tools being built against the old libraries.  
Fortunately, the behavior of wrong binaries looked something like this:

		Old Kernel (32-bit time_t)		New Kernel (64-bit time_t)
Old bins:		works						crashes
New bins:	works but shows wacky times		works

So I could at least install the new init/sh/cp without fear before rebooting 
into the new kernel.  Dynamic root made it necessary to use LD_LIBRARY_PATH 
quite liberally, but I was able to get enough working to complete the 
installworld.

Once that was done everything worked perfectly. :)  I'll have to recompile all 
the ports of course.  290 of them including kde and openoffice -- that will 
take a while ;)

So anyway, kudos to the FreeBSD development team!  It's certainly healthy for 
an OS to be able to survive a change in one of the base data types without 
suffering any major problems.  Something to think about for 6.x perhaps?

Random thoughts:
1. I was half expecting NFS to break -- mainly because of my ignorance of how 
things get from the VFS layer to the wire protocol.  Fortunately it seems the 
code is smarter than I gave it credit for.  I haven't tried serving yet, but 
the NFS client seems to interoperate fine with a stock FreeBSD 4.x server.

2. I was also slightly worried about the UFS on-disk layout.  Turns out that 
UFS already uses 64-bit timestamps anyway so I had nothing to worry about ;)

3. Should I expect any appreciable slowdown from using a non-native type for 
time_t?  So far I haven't noticed any difference, but I haven't done any 
scientific benchmarks or anything.

$ uname -a
FreeBSD aldaris 5.2-RC FreeBSD 5.2-RC #0: Sun Dec 21 20:44:33 CST 2003     
root_at_aldaris:/usr/obj/usr/src/sys/ALDARIS  i386
$ date -r 8589934592
Wed Mar 16 06:56:32 CST 2242
$ date -r 68719476736
Sun Aug 20 01:32:16 CST 4147
$ date -r 274877906944
Wed Jul 14 00:09:04 CST 10680