On Wed, 24 Feb 2016, Thomas Gleixner wrote: > On Fri, 12 Feb 2016, Arnd Bergmann wrote: > > Regarding the three versions, I think all of them are doable > > doable, and they all have their upsides and downsides but no > > showstoppers. > > > > Let me summarize what I see in the patches: > > > > 2a is the smallest set of changes in number of lines, as you indicated > > in the previous discussion (I was skeptical here initially, but > > you were right). The main downside is that each patch has to > > carefully consider what happens at the point when the type gets > > flipped, so that printk format strings are correct and assignments > > to local variables don't truncate the range. It also requires > > changing the types again after the VFS change, but that is > > something we can automate using coccinelle. > > Yes, you can do that final change with coccinelle, but all in all this has the > highest risk. Recent versions of Coccinelle can help a bit with format string changes. See demos/format.cocci. julia > > 2b has the main advantage of not changing behavior with the flip, so > > we can convert all file systems to use vfs_time relatively easily > > and then later make them actually use 64-bit timestamps with > > a patch that each file system developer can do for themselves. > > And that's a very clear advantage of this approch. The change is purely > mechanical and can be largely done with coccinelle. > > > One downside is that it leads to rather ugly code as discussed > > before, examples are in "[RFC v2b 5/5] fs: xfs: change inode > > times to use vfs_time data type" and "[RFC v2b 3/5] fs: btrfs: > > Use vfs_time accessors". > > - now = current_fs_time(inode->i_sb); > - if (!timespec_equal(&inode->i_mtime, &now)) > - inode->i_mtime = now; > + now = vfs_time_to_timespec(current_fs_time(inode->i_sb)); > + ts = vfs_time_to_timespec(inode->i_mtime); > + if (!timespec_equal(&ts, &now)) > + inode->i_mtime = timespec_to_vfs_time(now); > + > + ts = vfs_time_to_timespec(inode->i_mtime); > + if (!timespec_equal(&ts, &now)) > + inode->i_ctime = timespec_to_vfs_time(now); > > You can either provide a helper function which does that m/c_time update at > the VFS level where you can hide the mess or just accept that this transition > will introduce some odd constructs like the above. > > > 2c gets us the furthest along the way for the conversion, close > > to where we want to end up in the long run, so we could do that > > to file systems one by one. The behavior change is immediate, > > so there are fewer possible surprises than with 2a, but it > > also means the most upfront work. > > I would'nt worry about the upfront work to much, if it is the cleanest way to > do the conversion. Though, I'm not seing how that really makes the whole thing > simpler. > > So far we had good results with changing core code first and then fix up the > users one by one and at the end remove any intermediary helpers which we > introduced along the way. So I'd chose 2b as it's a very clear transition > mechanism with pretty low risk. > > Thanks, > > tglx > > > _______________________________________________ > Y2038 mailing list > Y2038@xxxxxxxxxxxxxxxx > https://lists.linaro.org/mailman/listinfo/y2038 > -- 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
