Ulrich Drepper <drepper@redhat.com> writes:
> Andi Kleen <ak@suse.de> writes:
>
> > For stat is also requires a changed glibc ABI -- the glibc/2.4 stat64
>
> Not only stat64, also plain stat.
>
> > structure reserved an additional 4 bytes for every timestamp, but these
> > either need to be used to give more seconds for the year 2038 problem
> > or be used for the ms fractions. y2038 is somewhat important too.
>
> The fields are meant for nanoseconds. The y2038 will definitely be
> solved by time-shifting or making time_t unsigned. In any way nothing
> of importance here and now. Especially since there won't be many
> systems which are running today and which have a 32-bit time_t be used
> then. For the rest I'm sure that in 37 years there will be the one or
> the other ABI change.
Right. Given current uptimes and being optimistic the fix for y2038
is probably needed by 2030 or just a little later. But in any case
64 bit systems should be maxing out by then, and the conversion to 128
bit systems should have already happened on the server side. 32 bit
systems will likely be limited to embedded and legacy systems by then.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:27 EST