Re: [RFC 00/32] making inode time stamps y2038 ready
From: H. Peter Anvin
Date: Mon Jun 02 2014 - 17:59:22 EST
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
>> 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...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/