系统调用是内核面向用户空间的接口。 用户进程通常不会直接调用它们，而是使用libc来做到这一点。 libc或者只是在系统调用时提供一个简单的包装器，或者在fork()和exec()的情况下做一些更多的工作，
所以我的问题是 – 内核的系统调用接口是否以不向后兼容的方式在内核版本之间改变？ 或者一旦系统调用build立，它永远不会改变？
系统调用是从应用程序代码的角度来看，一个基本的原子操作（它是一个“虚拟机指令”）。 另请参阅syscalls（2） 。
ABI指定了它是如何发生的。 对于x86-64，你可以在这里找到它。 另请参阅x86调用约定 。
对于一些系统调用，最近的内核提供了vdso（7）使其更快。
Linux内核尽力在二进制级别保持兼容性。 据传15年前（静态链接）的ELF可执行文件应该在最新的内核上运行。
但是，在实践中，你不能直接在你的代码中执行系统调用（因为你需要在汇编中做这件事，请参阅Linux程序集 ）。 你经常使用一些libc （例如GNU libc ，或者MUSL libc ）。 由于几个很好的原因，你通常动态链接你的程序到libc.so 那么，在很长的一段时间里，你可能会遇到一些不兼容的问题（一些链接到旧的libc二进制程序可能不会运行得更新或更老）。
由于以下原因，不会有大的变化：
fork()和exec()的libc版本非常小，它们与系统调用完全一样。 也许你正在考虑system() ，实际上fork-s，用exec调用一个shell并等待它的终止。
系统调用的重要性也低得多，他们并不被Linus和核心团队所喜欢，比如从_reiser4开始的系统调用，他们将来有更大的改变的机会。
但是标准的系统调用，例如sys_open ， sys_close等不会在最近的将来改变。
还有一件事情是可以改变的，不是系统调用，而是可以调用的方法。 在古人中，linux / i386使用了这个int 0x80 ，其中syscals的数量必须放在eax 。 从那以后，这个解决方案也变得更好/更快了，例如有一个CPU特有的SYSENTER asm-opcode，它也可以使用。 它们的可用性是特定于cpu的，因此它是第一次，当内核需要提供用户空间代码时 ，它的系统调用怎么会被调用。 如果你输入一个cat /proc/$$/maps ，你会在结尾看到一个[vdso]或者一个[vsyscall]内存区域。 较老的内核（也许在2.4？之前）没有它。