xfs
[Top] [All Lists]

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

To: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
Subject: Re: [RFC 00/32] making inode time stamps y2038 ready
From: Arnd Bergmann <arnd@xxxxxxxx>
Date: Wed, 4 Jun 2014 17:05:27 +0200
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, john.stultz@xxxxxxxxxx, hch@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, geert@xxxxxxxxxxxxxx, lftan@xxxxxxxxxx, hpa@xxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, ceph-devel@xxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, coda@xxxxxxxxxx, codalist@xxxxxxxxxxxxxxx, fuse-devel@xxxxxxxxxxxxxxxxxxxxx, linux-afs@xxxxxxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, linux-cifs@xxxxxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx, linux-mtd@xxxxxxxxxxxxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx, linux-ntfs-dev@xxxxxxxxxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, logfs@xxxxxxxxx, ocfs2-devel@xxxxxxxxxxxxxx, reiserfs-devel@xxxxxxxxxxxxxxx, samba-technical@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.1406022044090.27099@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <1401480116-1973111-1-git-send-email-arnd@xxxxxxxx> <4233989.Saca0ocOUr@wuerfel> <Pine.LNX.4.64.1406022044090.27099@xxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: KMail/1.12.2 (Linux/3.8.0-35-generic; KDE/4.3.2; x86_64; ; )
On Monday 02 June 2014, Joseph S. Myers wrote:
> 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 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

<Prev in Thread] Current Thread [Next in Thread>