为什么x86和x86_64中的Linux系统呼叫号码不同？

我知道系统调用接口是在较低级别上实现的，因此依赖于体系结构/平台，而不是“通用”代码。

但是，我不清楚为什么在32位x86内核的Linux中系统调用的编号在相似的体系结构Linux 64位x86_64中不保持相同的原因？做出此决定的动机/原因是什么？

我的第一个猜测是，后台原因是使32位应用程序在x86_64系统上可运行，因此通过合理地偏移系统调用号，系统将知道用户空间是32位还是64位分别。但是事实并非如此。至少在我看来，read（）是x86_64中的系统调用号0，无法与这种想法保持一致。

另一个猜测是，更改系统电话号码可能具有安全性/强化背景，而我无法确定自己的身份。

由于对实现与体系结构相关的代码部分所面临的挑战一无所知，我仍然想知道如何在似乎没有必要的情况下更改系统调用号（因为即使一个16位寄存器也将存储比当前约346个数字大得多的数字，以代表全部）调用），将有助于实现除破坏兼容性以外的任何功能（尽管通过库libc使用系统调用可以缓解这种情况）。

至于特定编号背后的原因，该编号与任何其他体系结构均不匹配[除了“ x32”实际上只是x86_64体系结构的一部分]：在Linux内核中对x86_64支持的早期，由于存在严重的向后兼容性限制，因此所有系统调用都已重新编号，以在高速缓存行使用级别对其进行优化。

我对内核开发的了解还不够，无法知道这些选择的具体依据，但是显然，在选择背后有一些逻辑，那就是用这些特定数字对所有内容重新编号，而不是简单地从现有体系结构中复制列表并删除未使用的列表。看起来顺序可能取决于调用它们的频率-例如，读/写/打开/关闭位于最前面。退出和派生似乎是“基本的”，但每个进程仅被调用一次。

可能还会在同一缓存行中保留共同使用的系统调用（这些值只是整数，但是内核中有一个表，每个表都有函数指针，所以每组8个系统调用占用该表的64字节缓存行）

看到以下问题的答案： “为什么amd64 linux中的系统调用号不同？” 在堆栈溢出。

总结一下：为了兼容，系统调用列表是稳定的并且只能增长。当x86 64体系结构出现时，ABI（参数传递，返回值）有所不同，因此内核开发人员借此机会带来了期待已久的更改。

简而言之，因为有人认为“ N+1做这些事的不相容的方法总比做的更好N”。对于历史拱门，通常选择syscall编号以匹配某些旧有的专有unix。但是对于x86_64，内核开发人员可以自由选择他们喜欢的任何编号。他们没有选择简单的选择并重复使用现有的编号，而是选择了发明新的标准。然后，他们又为aarch64和其他一些对象再次使用了它。这是Linux内核开发中经常重复使用的模式。