On Monday 19 May 2014 14:46:59 Joseph S. Myers wrote: > On Mon, 19 May 2014, Arnd Bergmann wrote: > > Now, when the motivation is not space reduction but ensuring nothing is > there that will break in 2038 (unless it's doing dubious things like > storing a time_t value in an int or long in the application - something a > reasonably stupid static analysis should be able to detect), you could > always identify the (symbol, version) pairs for a given architecture that > use 32-bit time_t and develop a tool that checks for binaries using > problem symbols. (Of course, that won't help with ioctls.) Or put a > small patch in the headers to force _TIME_BITS=64 and not allow an > override with _TIME_BITS=32. And if the kernel had a config option to > disable all the old interfaces, that would make problem binaries break now > rather than in 2038. I had already thought of the kernel option, that's probably one thing we will do here, but it won't help if glibc then emulates the interfaces we remove ;-) A related question would be how you plan to support future CPU architectures that never had the 32-bit time_t in the kernel ABI. Would you also want to provide both 32 and 64 bit time_t to user space on those? Then again I'm not sure how relevant glibc is to the deeply embedded distros that would want to run without the backwards compatibility. I suspect that uClibc, musl and bionic would just offer a compile time switch without any emulation. > > > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem > > > > problematic. > > > > > > Yes, we have a glibc bug > > > <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc > > > definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit > > > "long") being nonconforming, but without the kernel treating upper bits as > > > padding, fixing glibc requires wrappers that copy the value and clear the > > > upper bits. > > > > Ok. There is also work going on to have an x32-like ABI for ARM64, and > > that will likely have to support big-endian as well, so then it's not > > just about clearing the padding bits, but also having them in the right > > place. > > Yes, I see no problem with putting the padding bits in the right place so > that when the kernel is passing struct timespec values *to* userspace, it > can just fill in the native 64-bit structure and have it automatically be > correct when interpreted as a 32-bit structure with padding (which the > kernel will have zeroed implicitly) on tv_nsec. Ok. Arnd -- 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
