From owner-freebsd-current@FreeBSD.ORG Mon Dec 22 06:51:33 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 42B3C16A4CF for ; Mon, 22 Dec 2003 06:51:33 -0800 (PST) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F97643D5D for ; Mon, 22 Dec 2003 06:51:29 -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 EC22C2B4F9; Mon, 22 Dec 2003 08:51:28 -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 01324-05; Mon, 22 Dec 2003 08:51:28 -0600 (CST) Received: from owen1492.uf.corelab.com (pix.corelab.com [12.45.169.2]) by ion.gank.org (mail) with ESMTP id 7CB452B4D4; Mon, 22 Dec 2003 08:51:27 -0600 (CST) From: Craig Boston To: Peter Jeremy Date: Mon, 22 Dec 2003 08:51:23 -0600 User-Agent: KMail/1.5.4 References: <200312212239.38557.craig@xfoil.gank.org> <20031222080115.GA645@server.vk2pj.dyndns.org> In-Reply-To: <20031222080115.GA645@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312220851.24133.craig@xfoil.gank.org> X-Virus-Scanned: by amavisd-new at gank.org cc: current@freebsd.org Subject: Re: 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 14:51:33 -0000 On Monday 22 December 2003 02:01 am, Peter Jeremy wrote: > This has been discussed on either -arch or -hackers sometime in the > past year or so. Thanks -- my search-fu hasn't been good enough to summon those discussions yet but I'll keep looking. All I've found so far is some discussion of the filesystem timestamps, which seems to be moot now with UFS2. I suspect the biggest problem is figuring out a way to not break the ABI (some of my search hits vaguely mentioned new syscalls/libc functions, but those were referencing other posts I couldn't find). Also, I *thought* someone had done this before (on i386) and posted to -current or maybe -hackers about it, but now I can't seem to find it :( > Only UFS2. UFS1 has a 32-bit timestamp and an adjacent spare 32-bit field. That's funny. My filesystems are using UFS1 so that grub can read them :-/ > That's a good start. Have you tried cross-checking those calculations > via an independent codebase? (I have no idea whether they're right or > wrong but it's worth a double check). Not yet -- I don't have a real 64-bit platform to see what one says. I guess I could try doing the math by hand and see how it turns out. Would be nice if I could get the amd64 kernel booted in bochs ;) > The next test would be setting the date to (say) 2038-Jan-19 03:14 UTC, > waiting 10 seconds and seeing what various utilities do. Will do. This is my main PC at home so it should get a pretty thorough workout. Right now I'm recompiling world again because I didn't notice that struct timeval had long hard-coded for tv_sec :( I'm also building a list of ports that fail due to assumptions about sizeof(time_t) == sizeof(long). Ones that I'm able to fix I'll send patches to the developers for. So far the ones that have failed are: * ezm3 won't "compile". It seems to be already precompiled into assembly though, so I suspect it needs to be re-bootstrapped. I have no idea how to go about it, though. * ruby16 compiles but portupgrade tends to freeze and eat up 100% CPU. I tracked it down to a function being defined with time_t arguments but being called with longs. It didn't get automatically casted since the function in question used a K&R style declaration without a prototype, so it ended up with bogus data. Simple fix. * kdelibs3 won't compile. Opposite issue -- trying to pass time_t to a function declared for longs. Since it's C++ it just caused a compile error rather than strange results. I managed to work around it by statically casting to long, but it's not a correct fix and will break in 2038. --Craig