From owner-freebsd-current@FreeBSD.ORG Sun Dec 21 20:41:04 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0C3F16A4CE for ; Sun, 21 Dec 2003 20:41:04 -0800 (PST) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DFC943D50 for ; Sun, 21 Dec 2003 20:41:03 -0800 (PST) (envelope-from craig@xfoil.gank.org) Received: from localhost (ion.gank.org [69.55.238.164]) by ion.gank.org (mail) with ESMTP id 12FD42B4F9 for ; Sun, 21 Dec 2003 22:41:03 -0600 (CST) Received: from ion.gank.org ([69.55.238.164]) by localhost (ion.gank.org [69.55.238.164]) (amavisd-new, port 10024) with LMTP id 62215-06 for ; Sun, 21 Dec 2003 22:41:01 -0600 (CST) Received: from 192.168.69.78 (arbiter.gank.org [64.81.113.221]) by ion.gank.org (mail) with ESMTP id 6D0302B4D8 for ; Sun, 21 Dec 2003 22:41:00 -0600 (CST) From: Craig Boston To: current@freebsd.org Date: Sun, 21 Dec 2003 22:39:38 -0600 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312212239.38557.craig@xfoil.gank.org> X-Virus-Scanned: by amavisd-new at gank.org Subject: An experiment: 64-bit time_t on IA-32 (5.2-RC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2003 04:41:05 -0000 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@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