Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-26 Thread Deepa Dinamani
Arnd and I had a discussion about how to proceed here. We don't think anybody really is wanting a big patch touching 50 fs here. We are evaluating a couple of approaches that don't do this. I will post an update next week On Wed, Jan 20, 2016 at 3:17 PM, Arnd Bergmann wrote: > On Thursday 21

Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-26 Thread Deepa Dinamani
Arnd and I had a discussion about how to proceed here. We don't think anybody really is wanting a big patch touching 50 fs here. We are evaluating a couple of approaches that don't do this. I will post an update next week On Wed, Jan 20, 2016 at 3:17 PM, Arnd Bergmann wrote: >

Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-20 Thread Arnd Bergmann
On Thursday 21 January 2016 10:06:32 Dave Chinner wrote: > > IOWs, you're now finally suggesting doing the *simple conversion* > I've been suggesting needs to be made *since the start* of this > long, frustrating thread, except you *still want to abstract the > timestamp unnecessarily*. > > For

Re: [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-20 Thread Dave Chinner
On Tue, Jan 19, 2016 at 11:25:02PM +0100, Arnd Bergmann wrote: > On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote: > > You're doing it wrong. fat_time_fat2unix() still gets passed > > >i_mtime, and the function prototype is changed to a > > timespec64. *Nothing else needs to change*,

Re: [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-20 Thread Deepa Dinamani
On Tue, Jan 19, 2016 at 9:12 PM, Deepa Dinamani wrote: > > On Tue, Jan 19, 2016 at 2:25 PM, Arnd Bergmann wrote: >> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote: >>> On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote: >>> > On Mon, Jan 18, 2016 at 5:38 PM, Dave Chinner

Re: [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-20 Thread Deepa Dinamani
On Tue, Jan 19, 2016 at 9:12 PM, Deepa Dinamani wrote: > > On Tue, Jan 19, 2016 at 2:25 PM, Arnd Bergmann wrote: >> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote: >>> On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote: >>> > On Mon,

Re: [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-20 Thread Dave Chinner
On Tue, Jan 19, 2016 at 11:25:02PM +0100, Arnd Bergmann wrote: > On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote: > > You're doing it wrong. fat_time_fat2unix() still gets passed > > >i_mtime, and the function prototype is changed to a > > timespec64. *Nothing else needs to change*,

Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-20 Thread Arnd Bergmann
On Thursday 21 January 2016 10:06:32 Dave Chinner wrote: > > IOWs, you're now finally suggesting doing the *simple conversion* > I've been suggesting needs to be made *since the start* of this > long, frustrating thread, except you *still want to abstract the > timestamp unnecessarily*. > > For

[RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-06 Thread Deepa Dinamani
The current representation of inode times in struct inode, struct iattr, and struct kstat use struct timespec. timespec is not y2038 safe. Use scalar data types (seconds and nanoseconds stored separately) to represent timestamps in struct inode in order to maintain same size for times across 32

[RFC 02/15] vfs: Change all structures to support 64 bit time

2016-01-06 Thread Deepa Dinamani
The current representation of inode times in struct inode, struct iattr, and struct kstat use struct timespec. timespec is not y2038 safe. Use scalar data types (seconds and nanoseconds stored separately) to represent timestamps in struct inode in order to maintain same size for times across 32