On Fri, May 13, 2016 at 05:28:11PM +0200, Arnd Bergmann wrote: > I'm trying to understand what that means for the 64-bit time_t syscalls. > > The patch series I did last year had a replacement 'sys_newfstatat()' > syscall but IIRC no other stat variant, the idea being that we would > only need to provide this one to the libc and have user space emulate > the stat/fstat/lstat/fstatat variants based on that. > With the statx introduction, I was hoping to no longer have to add > that syscall but instead have libc do everything on top of sys_statx(). > > Do you think that is reasonable, given that we won't be allowed to > call any of the existing stat() variants for a y2038-safe libc build[1], > or should we plan to keep needing replacement fstatat (and possibly > stat/lstat/fstat) syscalls with 64-bit time_t even after statx() support > is merged into the kernel. Honestly I think this really matters on the amount of 'emulation' we need - if it's just adding a new flag that can be trivially generated in the syscall stub in userland that's probably fine, but if we have actually differing semantics (like the stat weak attributes) I'd rather have a properly documented syscall. If we otherwise need to rewrite whole structures I'd much rather do that in kernel space. And to get back to stat: if would be really useful to coordinate the new one with glibc so that we don't end up with two different stat structures again like we do for a lot of platforms at the moment. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
