On Friday 18 July 2014 14:15:07 Chung-Lin Tang wrote: > Hi Arnd, > Considering two other kernel interface issues that appeared earlier in > the context of nios2 glibc/kernel upstreaming: > > (1) The 64-bit time_t/timespec issue. > (2) Dropping renameat by default in favor of renameat2 > > What's the decision for these? Are they delayed to the next release? For renameat2, I believe we had patches to change the generic syscall list. It would be nice if you could include those in your patch series as a prerequisite and base your patches on top. Regarding time_t, I've spent much more time looking into what we need to do for the other 32-bit architectures now. My feeling now is that we're better off not introducing another special case for nios2 here, as that will have the effect of making it harder to move everyone else over later. We already have to deal with: - 32-bit architectures using 32-bit time_t - 64-bit architectures using 64-bit time_t - 64-bit architectures running 32-bit tasks with 32-bit time_t - 64-bit x86-64 and soon arm64 running x32 user space with 64-bit time_t and we will get in the future - 32-bit architectures providing both 32-bit time_t and 64-bit time64_t - 64-bit architectures with compat tasks running 64-bit time64_t Adding a 32-bit architecture that has a native 64-bit time_t will just add another special case that we will have to live with for a long time and that can introduce bugs for the other cases if we get it wrong. I vote for keeping 32-bit time_t on nios2 and fixing it along with arm32 and x86-32 and the others. Presumably this is not a huge problem for you as I expect it's easier for you to do another ABI change in user space when we get there: once we have support for 64-bit time64_t in the kernel, you can change your toolchains to default to that in user space and rebuild everything. This is not something we can easily do in x86. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
