Another Year Closer, Linux 4.21 Getting More Preparations For Y2038 Problem

Kernel changes continue flowing for addressing the "Year 2038" problem where on where on 19 January 2038 a signed 32-bit integer is no longer large enough for accommodating the number of seconds since 1970 as the 32-bit Unix time format.

Particularly over the past year or two, there's been an influx in kernel work for addressing the "Y2038" problem. With Linux 4.21, more work is slated to be merged. Per this pull request by veteran kernel developer Arnd Bergmann:

This concludes the main part of the system call rework for 64-bit time_t, which has spread over most of year 2018, the last six system calls being

- ppoll
- pselect6
- io_pgetevents
- recvmmsg
- futex
- rt_sigtimedwait

As before, nothing changes for 64-bit architectures, while 32-bit architectures gain another entry point that differs only in the layout of the timespec structure. Hopefully in the next release we can wire up all 22 of those system calls on all 32-bit architectures, which gives us a baseline version for glibc to start using them.

This does not include the clock_adjtime, getrusage/waitid, and getitimer/setitimer system calls. I still plan to have new versions of those as well, but they are not required for correct operation of the C library since they can be emulated using the old 32-bit time_t based system calls.

Aside from the system calls, there are also a few cleanups here, removing old kernel internal interfaces that have become unused after all references got removed. The arch/sh cleanups are part of this, there were posted several times over the past year without a reaction from the maintainers, while the corresponding changes made it into all other architectures.

There still is a lot of work ahead, but at least it looks like the support should be settled well ahead of 2038, assuming these 32-bit Linux systems shift to the latest software and remain deployed past January 2038.