From owner-freebsd-current@FreeBSD.ORG Mon Dec 22 22:52:48 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 4998716A4CE for ; Mon, 22 Dec 2003 22:52:48 -0800 (PST) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4858843D3F for ; Mon, 22 Dec 2003 22:52:44 -0800 (PST) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])hBN6qgoW030581; Tue, 23 Dec 2003 17:52:43 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost)hBN6qbrT030580; Tue, 23 Dec 2003 17:52:37 +1100 (EST) (envelope-from jeremyp) Date: Tue, 23 Dec 2003 17:52:36 +1100 From: Peter Jeremy To: Craig Boston Message-ID: <20031223065236.GA29936@cirb503493.alcatel.com.au> References: <200312212239.38557.craig@xfoil.gank.org> <20031222080115.GA645@server.vk2pj.dyndns.org> <200312220851.24133.craig@xfoil.gank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312220851.24133.craig@xfoil.gank.org> User-Agent: Mutt/1.4.1i 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: Tue, 23 Dec 2003 06:52:48 -0000 On Mon, Dec 22, 2003 at 08:51:23AM -0600, Craig Boston wrote: >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 Sorry, I didn't keep any references. > All I've found so far is some discussion of the >filesystem timestamps, which seems to be moot now with UFS2. It could be embedded in that discussion. There was also a discussion about extending various kernel interface types from 32 bits to 64 bits which discussed time_t and ABI issues associated with changing it. >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 :( I don't recall that. I notice time_t is 'long' on i386 so bde's ia32-with-64-bit-longs will also have 64-bit time_t. >> 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 :-/ /usr/src/sys/ufs/ufs/dinode.h on -stable: struct dinode { ... int32_t di_atime; /* 16: Last access time. */ int32_t di_atimensec; /* 20: Last access time. */ int32_t di_mtime; /* 24: Last modified time. */ int32_t di_mtimensec; /* 28: Last modified time. */ int32_t di_ctime; /* 32: Last inode change time. */ int32_t di_ctimensec; /* 36: Last inode change time. */ ... }; Looks like I was wrong about the adjacent field being spare - it seems it _has_ been used for high-res timestamps since I looked last. >> 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 was thinking of a totally independent implementation - eg the algorithms in Edward M. Reingold's "Calendrical Calculations". Agreeing with FreeBSD on an iA64 or amd64 could just be common bugs. >Right now I'm recompiling world again because I didn't notice that struct >timeval had long hard-coded for tv_sec :( gcc should be able to pick this up for you. >I'm also building a list of ports that fail due to assumptions about >sizeof(time_t) == sizeof(long). This isn't true now on Alpha and SPARC so I thought they had all been ironed out. You may still get bitten if sizeof(time_t) > sizeof(long). Good luck. Peter