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
years, which is way past the time that our planet can sustain
life of any form[1].
Did you mean mean 64 bits worth
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 version of
On Monday 02 June 2014 12:26:22 H. Peter Anvin wrote:
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
On Mon, 2 Jun 2014, Arnd Bergmann wrote:
Ok. Sorry about missing linux-api, I confused it with linux-arch, which
may not be as relevant here, except for the one question whether we
actually want to have the new ABI on all 32-bit architectures or only
as an opt-in for those that expect to stay
Typically they are using 64-bit signed seconds.
On May 31, 2014 11:22:37 AM PDT, Richard Cochran richardcoch...@gmail.com
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
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 changes seem like the sort of thing I'd expect, although
patches adding new syscalls or otherwise affecting the
