lkml.org 
[lkml]   [2014]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/25] Change time_t and clock_t to 64 bit
> > could do intelligent interpolation about what the epoch is, so in 2039
> > if we get a low 32 bit time_t value, we assume epoch == 1, conversely if
> > we see a high one, we assume epoch == 0. We could add epoch on the end
> > of the syscalls and detect if it's not present and fill in an
> > interpolated value. Interfaces which truly want 64 bit time_t would get
> > it from epoch + 32 bit time_t.

True sort of for the kernel (except you've got problems with file system
compatibility and I believe stuff like NFS and that fact some file
systems just break).

> The main advantage that I see with 64-bit time_t is that a lot of user
> space already works with it, because NetBSD and OpenBSD use this, and
> all 64-bit Linux systems already work with this without changing the ABI.
> If we want a POSIX extension to cover a new ABI, this would be the most
> likely candidate.

The main advantage IMHO of just using 64bit on 32bit boxes is getting it
right. I'd go so far as to consider changing userspace time_t to be a
struct. Yes it'll break lots of code but at least you'll know about it.

(and for some other systems like 2BSD it's probably the least of evils
because there isn't a 64bit type in the compiler!)

> As mentioned earlier, between kernel and user space it's probably best
> to avoid time_t and timeval completely and just use timespec64 or some
> other safe type, but there has to be a way to port user space that relies
> on time_t or timespec.

This I think is bang on. We've already got lots of cases where we can't
shoehorn useful info into syscalls due to time_t, including stuff like
exposing accurate stamps in stat(). On an 8MHz 68000 not much happened in
the same second, on a 32 core x86 it's a bit different.

Alan


\
 
 \ /
  Last update: 2014-05-15 23:41    [W:0.162 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site