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@xxxxxxxxxxxxx> wrote: > > > > > >> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote: > > > > > > 2. 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 -- 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
