CODEWITHSUNDEEP
linux-kernelx86x86-64system-calls
peachykeen
peachykeen

Reputation: 4421

Why is their a gap in syscall numbering between 334 and 424 in the x86-64 Linux kernel source?

In arch/x86/entry/syscalls/syscall_64.tbl syscalls are numbered from 0 to 334 and then there is a gap before the syscall numbers resume at 424. The relevant portion of the source is shown below:

...
333 common  io_pgetevents       sys_io_pgetevents
334 common  rseq            sys_rseq
# don't use numbers 387 through 423, add new calls after the last
# 'common' entry
424 common  pidfd_send_signal   sys_pidfd_send_signal
425 common  io_uring_setup      sys_io_uring_setup
...

Since new syscalls get added after number 439 (as stated in the comment), why does this large number gap exist?

Upvotes: 2

Views: 724

Answers (1)

jkr
jkr

Reputation: 19320

The purpose seems to be to sync up syscall numbers across architectures (source).

Viewing the git blame for the commented line in that file, one can find this commit message:

arch: add split IPC system calls where needed

The IPC system call handling is highly inconsistent across architectures, some use sys_ipc, some use separate calls, and some use both. We also have some architectures that require passing IPC_64 in the flags, and others that set it implicitly.

For the addition of a y2038 safe semtimedop() system call, I chose to only support the separate entry points, but that requires first supporting the regular ones with their own syscall numbers.

The IPC_64 is now implied by the new semctl/shmctl/msgctl system calls even on the architectures that require passing it with the ipc() multiplexer.

I'm not adding the new semtimedop() or semop() on 32-bit architectures, those will get implemented using the new semtimedop_time64() version that gets added along with the other time64 calls. Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().

Upvotes: 2

Related Questions