Thread (14 messages) 14 messages, 6 authors, 2019-05-30

Re: [PATCH 2/2] arch: wire-up clone6() syscall on x86

flat view

From: Arnd Bergmann <arnd@arndb.de>
Date: 2019-05-27 12:28:53
Also in: linux-arch, lkml

On Mon, May 27, 2019 at 12:45 PM Christian Brauner [off-list ref] wrote:
On Mon, May 27, 2019 at 12:02:37PM +0200, Arnd Bergmann wrote:
quoted
On Sun, May 26, 2019 at 12:27 PM Christian Brauner [off-list ref] wrote:
quoted
Wire up the clone6() call on x86.

This patch only wires up clone6() on x86. Some of the arches look like they
need special assembly massaging and it is probably smarter if the
appropriate arch maintainers would do the actual wiring.
Why do some architectures need special cases here? I'd prefer to have
new system calls always get defined in a way that avoids this, and
have a common entry point for everyone.

Looking at the m68k sys_clone comment in
arch/m68k/kernel/process.c, it seems that this was done as an
optimization to deal with an inferior ABI. Similar code is present
in h8300, ia64, nios2, and sparc. If all of them just do this to
shave off a few cycles from the system call entry, I really
couldn't care less.
I'm happy to wire all arches up at the same time in the next revision. I
just wasn't sure why some of them were assemblying the living hell out
of clone; especially ia64. I really didn't want to bother touching all
of this just for an initial RFC.
Don't worry about doing all architectures for the RFC, I mainly want this
to be done consistently by the time it gets into linux-next.

One thing to figure out though is whether we need the stack_size argument
that a couple of architectures pass. It's usually hardwired to zero,
but not all the time, and I don't know the history of this.

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