From mboxrd@z Thu Jan 1 00:00:00 1970 From: H. Peter Anvin Date: Mon, 02 Jun 2014 14:57:26 -0700 Subject: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready In-Reply-To: <7175692.dpgYFMbTaP@wuerfel> References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <4233989.Saca0ocOUr@wuerfel> <538CCFDE.2010107@zytor.com> <7175692.dpgYFMbTaP@wuerfel> Message-ID: <538CF346.2070504@zytor.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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... -hpa