I would like to discuss approaches to finish preparing the kernel to be y2038 ready.

Arnd started the effort a few years ago and I'm working on a few parts of the problem.

Background:

The y2038 problem arises because of time_t being defined as long, which is different between 32-bit and 64-bit systems. This leaves insufficient bits to represent time on a 32-bit system from the year 2038. time_t data type conversions can be broadly divided into the following sub categories:

* Internal kernel usage of time_t

* UAPI interfaces with time_t and derived types

* Userspace applications using time_t

Discussion motivation:

The solution to use a larger data type to represent time is rather straightforward and is agreed upon: Replace all time_t occurrences by time64_t, which is always defined to be s64.

The tricky part is how to reach the goal of this transition without breaking backward compatibility of interfaces internal and external to the kernel. This can be done in more than one way. After long discussions, we have managed to get some initial clean up patches merged. These will help the VFS transition to using time64_t. It is now a good time to look at the remaining problems in changing time_t.

Discussion topics:

The following are some key issues particularly needing discussion:

1. Time types we plan to retain within the kernel and in system APIs. We posted multiple series, there have been a few changes since then.

https://lkml.org/lkml/2014/5/30/669

https://lkml.org/lkml/2016/1/7/20

2. Syscall transition: Arnd had posted a version of this. There are a few updates here as well. I intend to post an update soon.

https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html

3. Policy for filesystems that do not support a y2038 safe on-disk representation: I posted a series and the initial xfstest patch.

https://lwn.net/Articles/705358/

https://www.spinics.net/lists/y2038/msg01945.html

4. VFS transition to using struct timespec64: I posted a few revisions and our approach has changed for the cleanup patches. A discussion would help pick an approach.

https://lwn.net/Articles/675381/

-Deepa