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

[Scott Long]

M. Warner Losh wrote:

> 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
> 

I think that we all owe AMD thanks and praise for blazing a trail out
of the 32bit Intel forest.

Now if you all are eager for upgrade unpleasantness, we can start
talking about 64-bit ino_t =-D

Scott