Re: [RFC 00/32] making inode time stamps y2038 ready
From: H. Peter Anvin
Date: Mon Jun 02 2014 - 15:28:13 EST
On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
> On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
>> On Fri, 30 May 2014, Arnd Bergmann wrote:
>>> a) is this the right approach in general? The previous discussion
>>> pointed this way, but there may be other opinions.
>> The syscall changes seem like the sort of thing I'd expect, although
>> patches adding new syscalls or otherwise affecting the kernel/userspace
>> interface (as opposed to those relating to an individual filesystem)
>> should go to linux-api as well as other relevant lists.
> 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.
> Two more questions for you:
> - are you (and others) happy with adding this type of stat syscall
> (fstatat64/fstat64) as opposed to the more generic xstat that has
> been discussed in the past and that never made it through the bike-
> shedding discussion?
> - once we have enough buy-in from reviewers to merge this initial
> series, should we proceed to define rest of the syscall ABI
> (minus driver ioctls) so glibc and kernel can do the conversion
> on top of that, or should we better try to do things one syscall
> family at a time and actually get the kernel to handle them
> correctly internally?
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.
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/