On Thu, Jan 14, 2016 at 05:53:21PM +0100, Arnd Bergmann wrote:
On Thursday 14 January 2016 08:04:36 Dave Chinner wrote:
On Wed, Jan 13, 2016 at 08:33:16AM -0800, Deepa Dinamani wrote:
On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote:
On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote:
On Jan 11, 2016, at 04:33, Dave Chinner david@fromorbit.com wrote: > On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote:
- How to achieve a seamless transition? Is inode_timespec solution agreed upon to achieve 1a?
No. Just convert direct to timespec64.
The hard part here is how to split that change into logical patches per file system. We have already discussed all sorts of ways to do that, but there is no ideal solution, as you usually end up either having some really large patches, or you have to modify the same lines multiple times.
The most promising approaches are:
a) In Deepa's current patch set, some infrastructure is first introduced by changing the type from timespec to an identical inode_timespec, which lets us convert one file system at a time to inode_timespec and then change the type once they are all done. The downside is then that all file systems have to get touched twice so we end up with timespec64 everywhere.
b) A variation of that which I would do is to use have a smaller set of infrastructure first, so we can change one file system at a time to timespec64 while leaving the common structures to use timespec until all file systems are converted. The downside is the use of some conversion macros when accessing the times in the inode. When the common code is changed, those accessor macros get turned into trivial assignments that can be removed up later or changed in the same patch.
c) The opposite direction from b) is to first change the common code, but then any direct assignment between a timespec in a file system and the timespec64 in the inode/iattr/kstat/etc first needs a conversion helper so we can build cleanly, and then we do one file system at a time to remove them all again while changing the internal structures in the file system from timespec to timespec64.
Just a clarification here: approaches b and c also need some functions that take times as arguments, including a function pointer in the vfs layer to be supported in both forms: timespec and timespec64 concurrently. As included in the cover letter, these are: generic_update_time(), inode->i_op->update_time(), lease_get_mtime(), fstack_copy_attr_all(), setattr_copy(), generic_fillattr().
-Deepa