Not need for new syscall

Posted May 30, 2019 22:53 UTC (Thu) by cyphar (subscriber, #110703)
In reply to: Not need for new syscall by Cyberax
Parent article: A ring buffer for epoll

We are running out of syscall space. 5.3 will probably have 434 common syscalls on all architectures, and there are apparently cache-related performance impacts once you pass 512 (on x86 at least). This doesn't mean we should always avoid new syscalls, but rather we should be careful when we add them. If the only user-facing purpose of a new syscall is to add a struct argument then we should look at doing it that way.

Not need for new syscall

Posted May 31, 2019 11:28 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

It seems there are two different issues here. One is the ABI used to call into the kernel on different architectures. That may support a fixed number of 'system call numbers' or have performance reasons to keep it down. The other is the API provided to the C library and by the C library to applications so they can call the familiar named functions like open(2) or kill(2). You could have an operating system running on i386 that used only a syscall number when calling into the kernel, but still provided the usual POSIX system call names. Is there a reason Linux can't add new "system calls" indefinitely in this way?

Not need for new syscall

Posted May 31, 2019 12:47 UTC (Fri) by smurf (subscriber, #17840) [Link]

Multiplex syscalls are generally frowned upon these days. Indirection eats another register for the "real" syscall number, tracing and syscall filtering get more complicated, … Besides, yes the syscall table would be full after adding the 512th entry, but extending it to 1024 is not exactly rocket science.

Adding a generator for these tables, in order to use a central point of syscall registry instead of the current arch hodgepodge, is certainly possible. Just do it …

Not need for new syscall

Posted Jun 1, 2019 15:24 UTC (Sat) by luto (guest, #39314) [Link]

What’s the issue on x86? As far as I know, the only real issue is running into the silly x32 aliases, but we can easily fix that.