cvs commit: src/sys/sys _timeval.h src/sys/fs/procfs procfs_status.c src/libexec/bootpd bootpd.c src/sys/dev/acpica/Osd OsdSynch.c src/sys/dev/firewire sbp.c

[M. Warner Losh]

In message: <20051227201654.GR63497 at over-yonder.net>
            "Matthew D. Fuller" <fullermd at over-yonder.net> writes:
: On Tue, Dec 27, 2005 at 11:50:31AM -0600 I heard the voice of
: Mark Linimon, and lo! it spake thus:
: > On Tue, Dec 27, 2005 at 09:38:11AM -0700, Scott Long wrote:
: > > I'll eat my hat if there is a FreeBSD/i386 in the year 2038.
: > 
: > Exist?  Hell, I'll bet that people will still be insisting we keep
: > the ports working on 4.11 even then.
: 
: Wait, are you suggesting that ports will stop working on my 2.1-STABLE
: box??  But it's at the absolute top of its particular branch of the
: tree!

5 years ago the hottest machines were ~1GHz Pentium III/IV boxes.  10
years ago they were ~133MHz Pentiums.  15 years ago we had ~33MHz
486.  20 years ago we had ~12MHz 386.

The chances that any of the hardware that's running FreeBSD today will
be in service in 2020, much less 2030 or 2038 is vanishingly small.
How many machines that were built in 1990 are still in service?  How
many from 1980?  How many from 1970?  How many from 1967?

There are good reasons to switch to a 64-bit time_t well in advance of
the 2038 deadline.  30-year mortgage calculations will be the first
class of things to fail.  The disruption from going to 64-bit time_t
is big, but mitigated somewhat by symbol versioning that was recently
introduced.  Most of the issues will be in kernel interfaces such as
stat, gettimeofday, etc.  One would need to write new syscalls for
them as well as preserve the old ones, and this is platform
dependent.  There's enough work here that unless someone steps to the
plate to deal with all the silly breakages, we'll only transition to
64-bit time_t on the non-alpha 64-bit machines...

Warner