On Thursday 12 May 2016 02:11:41 Christoph Hellwig wrote:

On Tue, May 10, 2016 at 09:25:55AM +0100, David Howells wrote:

quoted

Because it's not necessarily a perfectly working version of it.  See the Y2037
problem for example.

I was assuming that C libraries might want to update the struct stat and the
stat call() to provide fields that aren't currently there in Linux but are in
other OS's.  We could even dispense with older stat syscalls on new arches.

Please stop this whole let's get rid of old syscalls on new
architectures stuff.  This just means we have to do the translation
multiple, and the one in userspace is more costly as we it needs to be
in every copy of the library.  And times where we had a single libc
instance (nevermind implementation) are long over if we ever actually
had them.

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.

	Arnd

[1] the glibc developers plan to allow compatibility for 32-bit time_t
    and 64-bit time_t in the same binary, but any user space code built
    with 64-bit time_t must never call into kernel interfaces that use
    a 32-bit time_t.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html