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@xxxxxxxx> 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@xxxxxxxxxxxxx -- 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