[Top] [All Lists]

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

To: Arnd Bergmann <arnd@xxxxxxxx>
Subject: Re: [RFC 00/32] making inode time stamps y2038 ready
From: "H. Peter Anvin" <hpa@xxxxxxxxx>
Date: Mon, 02 Jun 2014 14:57:26 -0700
Cc: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, john.stultz@xxxxxxxxxx, hch@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, geert@xxxxxxxxxxxxxx, lftan@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, ceph-devel@xxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, coda@xxxxxxxxxx, codalist@xxxxxxxxxxxxxxxxxxxxxxxx, 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: <7175692.dpgYFMbTaP@wuerfel>
References: <1401480116-1973111-1-git-send-email-arnd@xxxxxxxx> <4233989.Saca0ocOUr@wuerfel> <538CCFDE.2010107@xxxxxxxxx> <7175692.dpgYFMbTaP@wuerfel>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
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 struct timespec to have a 64-bit time... it
>> isn't just about inodes.  We then should be explicit about the external
>> uses of time, and use accessors.
> I picked these because they are fairly isolated from all other uses,
> in particular since inode times are the only things where we really
> care about times in the distant past or future (decades away as opposed
> to things that happened between boot and shutdown).

If nothing else, I would expect to be able to set the system time to
weird values for testing.  So I'm not so sure I agree with that...

> For other kernel-internal uses, we may be better off migrating to
> a completely different representation, such as nanoseconds since
> boot or the architecture specific ktime_t, but this is really something
> to decide for each subsystem.

Having a bunch of different time representations in the kernel seems
like a real headache...


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