An experiment: 64-bit time_t on IA-32 (5.2-RC)
Peter Jeremy
PeterJeremy at optushome.com.au
Mon Dec 22 22:52:48 PST 2003
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
More information about the freebsd-current
mailing list