On Tuesday 02 February 2016 22:07:40 Deepa Dinamani wrote:
This patch series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros.
The idea for the series evolved from my discussions with Arnd Bergmann.
This was originally part of the RFC series[2]: https://lkml.org/lkml/2016/1/7/20 (under discussion).
Dave Chinner suggested moving bug fixes out of the feature series to keep the original series simple.
There are 354 occurrences of the the above macros in the kernel. The series will be divided into 4 or 5 parts to keep the parts manageable and so that each part could be reviewed and merged independently. This is part 1 of the series.
Looks very nice to me.
Motivation
The macros: CURRENT_TIME and CURRENT_TIME_SEC are primarily used for filesystem timestamps. But, they are not accurate as they do not perform clamping according to filesystem timestamps ranges, nor do they truncate the nanoseconds value to the granularity as required by the filesystem.
The series is also viewed as an ancillary to another upcoming series[2] that attempts to transition file system timestamps to use 64 bit time to make these y2038 safe.
There will also be another series[3] to add range checks and clamping to filesystem time functions that are meant to substitute the above macros.
Solution
CURRENT_TIME macro has an equivalent function:
struct timespec current_fs_time(struct super_block *sb)
These will be the changes to the above function:
- Function will return the type y2038 safe timespec64 in [2].
- Function will use y2038 safe 64 bit functions in [2].
- Function will be extended to perform range checks in [3].
I guess [2] and [3] are really independent of one another and can be done in either order, correct?
[2] will help to make 32-bit kernels work correctly on file systems that already support 64-bit timestamps internally, while [3] helps sanitize the behavior of file systems that cannot support that and that otherwise behave in unexpected ways on both 32-bit and 64-bit architectures.
Arnd