64 bit time_t

[M. Warner Losh]

In message: <18641.24692.875414.533794 at gromit.timing.com>
            John Hein <jhein at timing.com> writes:
: John Baldwin wrote at 13:21 -0400 on Sep 17, 2008:
:  > On Wednesday 17 September 2008 11:38:38 am John Hein wrote:
:  > > John Baldwin wrote at 10:40 -0400 on Sep 17, 2008:
:  > >  > And with amd64/x86-64, it may prove to not really be necessary.
:  > > 
:  > > I'm not sure I understand the "may" part.  Aren't we already using 64
:  > > bit time_t natively on amd64?  Or maybe you're talking about 32 bit
:  > > compat on amd64.
:  > 
:  > Yes, we are, and as newer server-class machines (at least) are predominantly 
:  > 64-bit, for at least the server-class market it would seem that boxes will 
:  > probably move to an amd64 kernel with a 64-bit time_t w/o requiring lots of 
:  > rototilling to support 64-bit time_t on i386.
: 
: Right.  I'm more concerned with planning now for y2038 on 32-bit
: embedded boxes that may still be around in 30 years.  In this case, I
: think it's easy enough for me to just change my local FreeBSD tree to
: have time_t be 64 bit and recompile.
: 
: But that doesn't help those users desperately clinging to their
: 7.1-RELEASE i386 boxes 30 years from now ;)

It won't be on FreeBSD/arm embedded boxes :-)

When we changed from 32-bit to 64-bit on arm, it wasn't a huge deal.
If you don't care about ABI compatibility, then it is a simple matter
of changing the definition of __time_t in sys/i386/include/_types.h
and rebuilding.  After all, there's no binaries not built as part of
the controlled build process that you use in certain embedded boxes
that I think you might be talking about ;-0.

All that system call and ioctl and structure compat stuff is
interesting, but just not relevant to your problem domain...

Warner