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

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