Re: An experiment: 64-bit time_t on IA-32 (5.2-RC)

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