Messages in this thread | | | Date | Mon, 02 Jun 2014 14:57:26 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [RFC 00/32] making inode time stamps y2038 ready |
| |
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
| |