Re: Fwd: Fifth draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Thu, Mar 2, 2017 at 6:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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).

Correct. I guess it will work out fine if all internal code in glibc tries the
64-bit time_t version of the kernel first and then falls back to the old
version just like a _TIME_BITS=64 process does, but the existing
entry point for _TIME_BITS=32 only calls the 32-bit time_t version of
the 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?

That is my current best guess, we'll only know for sure once a new
architecture gets merged, as this can theoretically change during review.

    Arnd