Thread (6 messages) 6 messages, 4 authors, 2014-06-04

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

From: Arnd Bergmann <arnd@arndb.de>
Date: 2014-06-04 15:05:27
Also in: ceph-devel, linux-arch, linux-btrfs, linux-cifs, linux-f2fs-devel, linux-fsdevel, linux-nfs, linux-scsi, linux-xfs, lkml, ocfs2-devel

On Monday 02 June 2014, Joseph S. Myers wrote:
On Mon, 2 Jun 2014, Arnd Bergmann wrote:
quoted
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 around for another 24 years.
For glibc I think it will make the most sense to add the support for 
64-bit time_t across all architectures that currently have 32-bit time_t 
(with the new interfaces having fallback support to implementation in 
terms of the 32-bit kernel interfaces, if the 64-bit syscalls are 
unavailable either at runtime or in the kernel headers against which glibc 
is compiled - this fallback code will of course need to check for overflow 
when passing a time value to the kernel, hopefully with error handling 
consistent with whatever the kernel ends up doing when a filesystem can't 
support a timestamp).  If some architectures don't provide the new 
interfaces in the kernel then that will mean the fallback code in glibc 
can't be removed until glibc support for those architectures is removed 
(as opposed to removing it when glibc no longer supports kernels predating 
the kernel support).
Ok, that's a good reason to just provide the new interfaces on all
architectures right away. Thanks for the insight!

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help