Re: Fwd: Fifth draft of the Y2038 design document

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 2 Mar 2017, Arnd Bergmann wrote:

> > I do expect the functions that use times internally but not in their
> > interface to be able to be changed to use 64-bit-time interfaces
> > unconditionally, and for this to work on an old kernel.  (Whether this is
> > needed for calls to e.g. __xstat64 if times aren't actually used from the
> > resulting structure would depend on what __xstat64 does with too-large
> > timestamps; if the kernel saturates them, a change may not strictly be
> > needed, but if EOVERFLOW errors occur then a change would be needed.  And
> > given the desire to support kernels with 32-bit-time syscalls disabled, a
> > change to such calls is probably desirable in any case.)
> 
> The idea for stat is that:
> 
> - The old 'stat/utimes' syscalls get modified to do correct saturation for both
>   file-system specific limits and 32-bit time_t limits.

So random calls to __xstat64 in glibc in code that doesn't use the time 
parts of the result wouldn't need changing for that code to work with 
files with post-2038 timestamps - but would need changing to use 
__xstat64_time64 if we want them to work with kernels that disable the old 
syscalls (and if __xstat64 continues to use the old syscalls).

> - The newly added (as of linux-4.12) statx() syscall gets used as the
>   replacement for the entire stat family of syscalls with 64-bit time_t.

Does that then become the only stat-family syscall provided for all new 
architectures added in 4.12 and later?

-- 
Joseph S. Myers
joseph@codesourcery.com