lkml.org 
[lkml]   [2016]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Y2038] [RFC v2] vfs 64 bit time transition proposals
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
>

\
 
 \ /
  Last update: 2016-02-24 14:01    [W:0.050 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site