Re: [f2fs-dev] [RFC 00/32] making inode time stamps y2038 ready

2014-06-06 Thread H. Peter Anvin
On 06/04/2014 12:24 PM, Arnd Bergmann wrote: > > For other timekeeping stuff in the kernel, I agree that using some > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds, > ...) has advantages, that's exactly the point I was making earlier > against simply extending the internal

Re: [f2fs-dev] [RFC 00/32] making inode time stamps y2038 ready

2014-06-02 Thread H. Peter Anvin
Typically they are using 64-bit signed seconds. On May 31, 2014 11:22:37 AM PDT, Richard Cochran wrote: >On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote: >> >> It's an approximation: > >(Approximately never ;) > >> with 64-bit timestamps, you can represent close to 300 billion >>

Re: [f2fs-dev] [RFC 00/32] making inode time stamps y2038 ready

2014-06-02 Thread H. Peter Anvin
On 06/02/2014 12:19 PM, Arnd Bergmann wrote: > On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote: >> On Fri, 30 May 2014, Arnd Bergmann wrote: >> >>> a) is this the right approach in general? The previous discussion >>>pointed this way, but there may be other opinions. >> >> The syscall cha

Re: [f2fs-dev] [RFC 00/32] making inode time stamps y2038 ready

2014-06-02 Thread H. Peter Anvin
On 06/02/2014 12:55 PM, Arnd Bergmann wrote: >> >> The bit that is really going to hurt is every single ioctl that uses a >> timespec. >> >> Honestly, though, I really don't understand the point with "struct >> inode_time". It seems like the zeroeth-order thing is to change the >> kernel internal