[lkml]   [2002]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: New nanosecond stat patch for 2.5.44
Followup to:  <>
By author: Andreas Dilger <>
In newsgroup:
> 3) The fields you are usurping in struct stat are actually there for the
> Y2038 problem (when time_t wraps). At least that's what Ted said when
> we were looking into nsec times for ext2/3. Granted, we may all be
> using 64-bit systems by 2038... I've always thought 64 bits is much
> to large for time_t, so we could always use 20 or 30 bits for sub-second
> times, and the remaining bits for extending time_t at the high end,
> and mask those off for now, but that is a separate issue...

64-bit time_t is nice because you don't *ever* need to worry about
overflow; it's capable of handling times on a galactic lifespan
scale. It's overkill, of course, but it's the *right* kind of

We probably need to revamp struct stat anyway, to support a larger
dev_t, and possibly a larger ino_t (we should account for 64-bit ino_t
at least if we have to redesign the structure.) At that point I would
really like to advocate for int64_t ts_sec and uint32_t ts_nsec and
quite possibly a int32_t ts_taidelta to deal with leap seconds... I'd
personally like struct timespec to look like the above everywhere.


<> at work, <> in private!
"Unix gives you enough rope to shoot yourself in the foot." <>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:30    [W:0.079 / U:4.040 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site