From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754166AbcBXM0R (ORCPT ); Wed, 24 Feb 2016 07:26:17 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:30589 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752305AbcBXM0Q (ORCPT ); Wed, 24 Feb 2016 07:26:16 -0500 X-IronPort-AV: E=Sophos;i="5.22,493,1449529200"; d="scan'208";a="165824952" Date: Wed, 24 Feb 2016 07:26:12 -0500 (EST) From: Julia Lawall X-X-Sender: jll@hadrien To: Thomas Gleixner cc: Arnd Bergmann , "' Theodore Ts'''o" , y2038@lists.linaro.org, david@fromorbit.com, linux-kernel@vger.kernel.org, Deepa Dinamani , linux-fsdevel@vger.kernel.org Subject: Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals In-Reply-To: Message-ID: References: <20160212092153.GA2368@deepa-ubuntu> <2477494.8uiLi5Mt41@wuerfel> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/y2038 >