On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote: > Err, we CANNOT do that. We cannot move ANY 32 bit architecture to > 64bit time_t without breaking the world and some more. Of course we can, we just need to still provide the existing 32-bit time_t ABIs for backwards compatiblity. That's how we handled extensions of other types like off_t in the past. > All 64bit architectures use 64bit time_t already plus the x32 ABI of x86. 64-bit is not relevant for the pain as there time_t is simply a long, while for 32-bit types we move to a longer than pointer sized type, in direct contradiction to older standards the explicitly prohibit this. > So why would user space explode? It did not explode with x32 Who knows? It's not like x32 actually has any significant user base. In fact just weeks ago we fixed fundamental type system bugs for it. > and it > would be dumb as hell to have new archs use time_t 32bit when we are > currently twisting our brain around how to solve the y2038 > problem. Simply because we can not do the BSD flag day approach and > change it. I don't think it's a good idea to have minor new architectures pointlessly different than the major ones. Especially given that we'll absolutely have to fir the y2038 problem for 32-bit arm and probably x86 anyway. -- 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
