Thread (9 messages) 9 messages, 3 authors, 2017-06-20

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

From: Yury Norov <hidden>
Date: 2017-06-20 13:37:14
Also in: linux-arch

On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
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>
Thanks,
quoted
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"!

Cheers
James
(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?

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?

Yury
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help