On 10/29/2010 2:25 AM, Arnd Bergmann wrote: > On Thursday 28 October 2010, Chris Metcalf wrote: >> The alternative is keeping the two structures the same shape on 64-bit >> kernels, which means a 64-bit time_t in "struct stat64" for 32-bit >> processes. This is a little unnatural since 32-bit userspace can't >> do anything with 64 bits of time_t information, since time_t is just >> "long", not "int64_t"; and in any case 32-bit userspace might expect >> to be running under a 32-bit kernel, which can't provide the high 32 >> bits anyway. In the case of a 32-bit kernel we'd then be extending the >> kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits >> again in userspace, for no particular reason. And, as mentioned above, >> if we have 64-bit time_t for 32-bit processes we can't easily use glibc's >> STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded >> "struct timespec", which is a pair of "long" (32-bit) values in a 32-bit >> userspace. "Inventive" solutions are possible, but are pretty hacky. > I'd like to have more opinions on that. Would it be less crazy > to ignore the y2k38 problem for new 32 bit architectures given that > we already know about it, or to make those architectures unnecessarily > slow, given that we still have 27+ years before it hits people in > a major way? > > I think we have four alternatives here: > > 1. this patch, which is the easiest solution and keeps everything else > working, but not solving the y2k38 problem on 32 bit. Perhaps unsurprisingly, I think this patch strikes a good balance for today of allowing <asm-generic/stat.h> to work in the "obviously correct" way for 64-bit platforms, but without addressing the larger issues. > 2. make __kernel_time_t 64 bit on new architectures, solving the y2k38 > problem for them at the cost of run-time overhead and possibly application > porting effort. > > 3. make struct stat use a 64 bit time field on new architectures at the > cost of not using STAT_IS_KERNEL_STAT in 32 bit glibc. > > 4. leave struct stat as it is, and move to struct xstat that does > everything right from the start. I'd argue that the longer-term plan might be to work with the glibc community to spec out what the eventual 64-bit time_t APIs will look like for user-space, and then think about implementing them using xstat() with 64-bit time_t. Once this is in place, the kernel will need to move to 64-bit __kernel_time_t enough in advance of 2038 to hope that it's widely-deployed in embedded systems, etc., by then. But I think this all represents a more ambitious project than we need today. > Your patch looks correct for solution 1, I can forward it if we decide > to do it this way, or you can take it in your series. > > Acked-by: Arnd Bergmann <arnd@xxxxxxxx> Thanks! -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html