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: > 1. Function will return the type y2038 safe timespec64 in [2]. > 2. Function will use y2038 safe 64 bit functions in [2]. > 3. 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 -- 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
