Linux：系统调用会改变吗？

Question

Syscalls是内核的面向用户空间的接口。用户进程通常不会直接调用它们，而是使用libc来执行此操作。 libc要么只是在系统调用周围提供一个瘦包装，要么像fork()和exec()那样做更多的工作

所以我的问题是 - 内核的syscall接口是否以非向后兼容的方式在内核版本之间发生变化？或者，一旦建立了系统调用，它就永远不会改变？

Answer 1

从应用程序代码的角度来看，syscall是基本的原子操作（它是“虚拟机指令”）。另请参阅syscalls(2)。

ABI指定它究竟是如何发生的。对于x86-64，您可以找到它here。另请参阅x86 calling conventions。

对于某些系统调用，最近的内核提供vdso(7)以使它们更快。

Linux内核努力保持二进制级别的兼容性。据传，15年前（静态链接）ELF可执行文件应该在最新的内核上保持不变。

但是，在实践中，您不会直接在您的代码中执行系统调用（因为您需要在汇编中执行此操作，请参阅Linux assembly howto）。您经常使用一些libc（例如GNU libc或MUSL libc）。出于几个好的原因，您通常会将程序动态链接到libc.so。然后你可能会在很长一段时间内遇到一些不兼容问题（一些链接到旧libc的二进制程序可能不会运行得更新 - 或者更旧 - 一个）。

Answer 2

由于以下原因，预计不会发生重大变化：

1. 虽然它们主要通过libc调用，但是可以更改libc - 它会在内核和libc版本之间产生兼容性问题，这需要避免。
2. Syscalls的标准化与libc调用完全相同。

fork()和exec()的libc版本非常小，它们与系统调用完全一样。也许你正在考虑system()，它实际上是fork-s，用exec调用shell并等待它的终止。

还有一些系统调用的重要性低得多，Linus和核心团队并不喜欢它们，例如以_ reiser4 开头的系统调用......，它们有更大的重要性未来有机会改变。

但标准的系统调用，例如sys_open，sys_close等，在最近的将来不会发生变化。

---

还有一件事可以改变，它不是系统调用，而是可以调用的方法。在古人中，linux / i386使用了int 0x80，其中系统密码的数量必须放在eax中。从那时起，它也出现了更好/更快的解决方案，例如，有一个特定于CPU的SYSENTER asm-opcode，也可以使用。它们的可用性是特定于cpu的，因此它是第一次，当内核需要提供用户空间代码时，如何调用它的系统调用。如果您输入cat /proc/$$/maps，您会看到最后一个[vdso]或[vsyscall]内存区域，这是。较旧的内核（可能在2.4？之前）没有它。