Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1407238

Re: [GIT PULL] y2038 changes for vfs

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[GIT PULL] y2038 changes for vfs Arnd Bergmann <arnd@arndb.de> - 2016-05-24 22:20 +0200
  Re: [GIT PULL] y2038 changes for vfs Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-25 00:30 +0200
    Re: [GIT PULL] y2038 changes for vfs Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-25 00:50 +0200
      Re: [GIT PULL] y2038 changes for vfs Deepa Dinamani <deepa.kernel@gmail.com> - 2016-05-25 02:20 +0200
    Re: [GIT PULL] y2038 changes for vfs Arnd Bergmann <arnd@arndb.de> - 2016-05-25 18:10 +0200
      Re: [GIT PULL] y2038 changes for vfs Dave Chinner <david@fromorbit.com> - 2016-05-25 23:40 +0200

csiph-web