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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
