问题描述
在arch/x86/entry/syscalls/syscall_64.tbl中，系统调用的编号从0到334，然后在424之前系统调用恢复之前有一个间隔。源的相关部分如下所示：
...
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
...
由于新的系统调用在编号439之后添加（如评论中所述），为什么存在如此大的缺口？
解决方法
目的似乎是跨体系结构（source）同步系统调用号码。
查看git blame for the commented line in that file，可以找到以下提交消息：
arch：在需要的地方添加拆分的IPC系统调用
IPC系统调用处理在各个体系结构中是高度不一致的， 有些使用sys_ipc，有些使用单独的调用，有些同时使用。我们也 有一些架构需要在标志中传递IPC_64，并且 其他隐式设置它的人。
为添加y2038安全semtimedop（）系统调用，我选择仅 支持单独的入口点，但这需要首先支持 具有自己的系统调用号的普通服务器。
新的semctl / shmctl / msgctl系统现在隐含IPC_64 甚至在需要使用ipc（）传递架构的调用 多路复用器。
我没有在32位体系结构上添加新的semtimedop（）或semop（）， 这些将使用新的semtimedop_time64（）版本实现 与其他time64调用一起添加。 三种64位体系结构（powerpc，s390和sparc）获得semtimedop（）。