Re: [GIT PULL] y2038 changes for vfs

[Dave Chinner <david@fromorbit.com>]

On Wed, May 25, 2016 at 06:03:19PM +0200, Arnd Bergmann wrote:
> On Tuesday, May 24, 2016 3:23:39 PM CEST Linus Torvalds wrote:
> > On Tue, May 24, 2016 at 1:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb:
> > >
> > >   Linux 4.6-rc3 (2016-04-10 17:58:30 -0700)
> > >
> > > are available in the git repository at:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git tags/y2038-4.7
> > 
> > The more I look at this, the less I like it.
> > 
> > There doesn't even seem to be any *point* to the preparatory patches.
> > I'm not seeing what any of those patches actually help prepare. The
> > two new superblock fields that it adds, for example, should likely
> > never be touched directly by any code in the first place, so adding
> > them only encourages people to add more "preparatory" patches to
> > filesystems that simply don't seem sensible.
....
> > It's not like it's hard to compile-test the pretty mechanical
> > conversion. There are no architecture-specific users, so I suspect
> > that a trivial "make allmodconfig" build will catch all the cases.
> > 
> > Why drag something like this out, in other words?

Good question, indeed.

> The vfs_time_to_timespec/timespec_to_vfs_time accessors and the
> s_time_min/s_time_max patch are really the ones that make most
> sense doing per file system. These are still all really simple
> patches, but it seemed logical to keep all three together and then
> go through each file system one by one. The hard part here is
> really catching the attention of the file system maintainers,
> not doing the patches.

I was the only filesystem person who attempted to the review your
changes 3 months ago. After the amount of shit you and Deepa dragged
me through as I tried to get you to restructure the patchset
*exactly* like Linus us now suggesting, I walked away and haven't
looked at your patches since.  Is it any wonder that no other
filesystem maintainer has bothered to waste their time on this
since?

Linus - I'd suggest these VFS timestamp patches need to go through
Al's VFS tree. That way we don't get unreviewed VFS infrastructure
changes going into your tree via a door that nobody was paying
attention to...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com