On Tue, Jun 20, 2017 at 04:20:43PM +0200, Arnd Bergmann wrote:

On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov [off-list ref] wrote:

quoted

On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:

quoted

On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:

quoted

On Mon, Jun 19, 2017 at 11:42 PM, James Hogan [off-list ref] wrote:

quoted

On Mon, Jun 19, 2017 at 06:49:46PM +0300, Yury Norov wrote:
Subject: [PATCH] Deprecate stat syscalls superseded by statx

Various stat system calls can now be implemented as userland wrappers
around the new statx system call, so allow them to be removed from the
kernel by default for new architectures / ABIs.

This involves adding __ARCH_WANT_SYSCALL_UNXSTAT to each existing
architecture, which enables the relevant stat system calls in the
generic system call list (if used). It also conditionally defines the
syscalls in fs/stat.c and struct stat / struct stat64 in
asm-generic/stat.h.

Signed-off-by: James Hogan <redacted>
Cc: David Howells <dhowells@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Good idea:

Acked-by:  Arnd Bergmann <arnd@arndb.de>

quoted

+/* statx deprecates the un-extended stat syscalls which use struct stat[64] */
+#ifdef __ARCH_WANT_SYSCALL_UNXSTAT

I'm glad you explain what 'UNXSTAT' means here, since I would not
have otherwise guessed it, but I also can't think of anything more
intuitive.

Yeh, I renamed that several times while playing around with this :-).

The stat syscalls remind me a bit of the Vicar of Dibley episode where
the new road named "New Road" necessitates the renaming of the existing
"New Road" to "Quite Old Road" and "Quite Old Road" to "Really Quite Old
Road" and "Old Road" to "Very Old Road"!

(Add Palmer Dabbelt [off-list ref])

The stat syscalls are full of hacks, and we have to pull that hacks
even to new architectures to deal with stat. So I'll be happy to drop
it in arm64/ilp32. But it means that I need some time to integrate
your patch and fix glibc accordingly. And it also means that we need
round 9 for ilp32... :(

Arnd, once before you told that generic unistd has some duplications
and legacy syscalls, and one day we'll have to deal with it. Do you
have the list or something on it?

No, I'd have to do some research for that.

quoted

I would also notice riscv people and welcome to the discussion.

As there is more than 1 arch that goes to be added to linux soon,
maybe it's better to upstream my ans James' patches separately
from other ilp32 patches? Arnd?

Do you mean upstream those two patches slightly later? That's
fine with me, I don't care much whether the old new stat is part
of the syscall table for arm64-ilp32 or not, I'd leave that up to
you, depending on whether you want to do the rework or not.

 
I mean that if we want to deprecate rlimit and stat syscalls for
architectures that are under development now, it's better to upstream
patches that actually deprecate it as early as possible. 

I suppose the arm64-ilp32 could benefit from not having to support
the old arm32 stat structure, but doing the new syscalls based on
statx could delay the glibc port some more, as there are some open
questions about how that would best be integrated.

OK. Let's leave things as is. But then I don't see any reason to
add unxstat patch to ilp32 series if ilp32 will not disable it.

Yury