是否有原始的 linux 系统调用 API/ABI 文档答案

【问题标题】：Is there raw linux system call API/ABI documentation是否有原始的 linux 系统调用 API/ABI 文档
【发布时间】：2016-03-16 04:56:15
【问题描述】：

系统调用有 man(2) 页面，但这些页面描述了位于系统调用之上的 C 库 (glibc) 的行为。原始系统调用 API/ABI 是否记录在某处（UseTheSourceLuke 除外）？我在手册页中看到了一些关于内核/libc 之间差异的内容，但我并没有感觉到记录这些差异是当务之急。

我真正想说的是：C 库是否被 POLICY 视为稳定/记录的 Linux API，而内核的系统调用 API/ABI 被认为是不稳定的（可能会更改），因此故意未记录或低优先级？

所以更改系统调用的内核开发人员会在 glibc 中使用变通方法？那么其他的 libc 呢？

我能找到关于这个主题的历史讨论吗？

编辑：所以 ABI 是稳定的，系统调用的行为也是如此，但内核开发人员没有记录它们。 glibc 正在记录它们（带有自己的添加/更改）。对吗？

【问题讨论】：

re：历史讨论。您可能会发现一些 here。没有深度，但更多的是对主题的概述，包括 API/ABI。
如果您询问如何将系统调用参数传递给内核，那么 ABI 在给定的处理器架构中是稳定的。跨处理器架构是您将看到 ABI 差异的地方。
如果 ABI 是稳定的，而且系统调用的行为也是稳定的，我猜可能会有它的文档。
它是稳定的（对于特定架构），因为更改向后兼容以避免破坏旧的用户空间代码。
很有可能为 12 年前最新的稳定内核（即 v2.6 行之一）编写的 Linux libc 可以与现代内核一起使用。实际上，您可以在 RHEL / CentOS 6 中看到这种情况，它基于 2.6 系列内核，但您可以轻松切换到更新的内核，例如通过从 EL-repo 安装内核包。

标签： c linux api assembly kernel

【解决方案1】：

我认为内核开发人员实际上并没有发布中断 API，但您可以找到像 this one 这样的第三方图表。

【讨论】：

当然，如果您确实需要这样的图表，那么您应该选择一个与您的内核版本相匹配的图表。链接到的是Linux 2.2。因此，它在 2004 年发布时有点过时，现在已经过时了。
@JohnBollinger - 确实是针对较旧的内核版本，但该页面的作者还为您提供了为较新内核创建自己的图表的资源。此外，尽管您说它“已经过时”，但许多调用并未更改为最新内核。（我在实现自己的编译器时测试了几个。）
@JohnBollinger：owacoder 是正确的。 Linus 一直非常坚持不破坏用户空间 ABI。他们没有修改现有的系统调用，而是使用新名称添加了新版本的系统调用。所以你会找到像mmap2(2) 这样的东西，用于将大偏移量映射到 32 位系统上的大文件中。在内部，旧的系统调用入口点通常成为在新函数之上实现旧行为的包装器。因此，新图表将具有现在首选的新版本的系统调用。

【解决方案2】：

您的问题的答案是在syscall man page。特别注意标题“架构调用约定”部分，并注意上面 John Bollinger 提到的这些信息可能因内核版本而异。

【讨论】：

【解决方案3】：

我真正想说的是：C 库是否被 POLICY 视为稳定/记录的 Linux API，而内核的系统调用 API/ABI 被认为是不稳定的（可能会更改），因此故意未记录或低优先级？

如果不为what指定谁的政策，就不可能与政策对话。

为“Linux”编程的人通常实际上是为一种或多种 GNU/Linux 编程，而不是为裸内核编程。因此我倾向于说我们可能没有考虑内核开发者政策。事实上，如果 C 库接口完全可用，那么我们不是在谈论裸内核。此外，根据您的标记，我假设您正在询问 C 编程。如果您在汇编中进行编程，那么原始系统调用接口将是自然而适当的，而我的其余 cmet 中的大多数都将不适用。

如果您确实将 GNU / Linux 排除在外，那么这个问题就有点明智了。另一方面，通常情况下，人们更愿意为更广泛的兼容性进行编程。在这种情况下，除了使用 C 库系统调用接口之外，确实没有其他选择，因为每个系统的原始系统调用都是不同的。 Glibc 的系统调用接口在符合 POSIX 和 SUS 方面做得很好，因此（正确地）使用它们对于可移植性来说是一个巨大的优势。即使其他 Unix 和类 Unix 系统（例如 OS X、BSD、Solaris 等）不是直接目标，保持在这些系统上使用您的软件的可能性也很少有损失。

无论如何，如果您决定让您的软件直接执行 Linux 系统调用，那么您真的会在任何您想要的地方插入内联汇编来执行此操作吗？当然不是——你会编写包装函数。那么，您为什么要反对使用 C 库已经提供的经过彻底测试和有据可查的包装函数呢？

当然，Linux 系统调用接口确实在内核版本之间发生了一定程度的变化。这可以被认为是使版本不同（我的意思是 x.2y -> x.2z 或 x.y -> z.w）。我不太了解此类更改通常有多大，但过去曾发生过不兼容的更改，并且使用 C 库接口可以在某种程度上使您免受此类更改的影响。然而，如上所述，我认为更喜欢 C 库接口还有其他更大的原因。

【讨论】：

关于政策，我的意思是内核开发人员的政策。如果我想编写一个只有裸 linux 内核的嵌入式平台，在这种情况下我从哪里获得文档？在那种情况下是否没有记录？
@ctrl-d，那么看在上帝的份上，你为什么不这么说呢？如果您没有 C 库可供使用，则 C 库接口没有实际意义。请修改您的问题，询问您真正想知道的内容。
对不起，如果我造成了混乱，真的。这是一个关于政策的理论问题，而不是实践本身。否则我应该怎么问这个问题？
@ctrl-d，如果您假设直接系统调用，那么除了否认其使用之外，任何提及 C 库都是一个红鲱鱼，应该避免。您似乎真的很想问的问题是“我在哪里可以找到 Linux 原始系统调用的文档？”，也许会加上“它们有多稳定？”。前者不是，实际上是一个政策问题，尽管后者确实涉及内核开发政策。
也许我应该把它单独放在标题上。但我不同意您的观点，即开发人员为原始内核制作文档或不为原始内核制作文档不是政策规定。