Date: Tue, 27 Dec 2005 14:12:40 -0700 From: Scott Long <scottl@samsco.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: trhodes@FreeBSD.org, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, fullermd@over-yonder.net, linimon@lonesome.com Subject: Re: 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 Message-ID: <43B1AE48.3000009@samsco.org> In-Reply-To: <20051227.140049.73660062.imp@bsdimp.com> References: <43B16DF3.2060102@samsco.org> <20051227175031.GB8852@soaustin.net> <20051227201654.GR63497@over-yonder.net> <20051227.140049.73660062.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <20051227201654.GR63497@over-yonder.net> > "Matthew D. Fuller" <fullermd@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43B1AE48.3000009>