有没有原始的Linux系统调用API / ABI文档
系统调用有2个页面，但这些页面描述了位于系统调用之上的C库（glibc）的行为。 原始系统调用API / ABI记录在某处（UseTheSourceLuke除外）？ 我在man手册中看到了一些关于kernel / libc的差异，但我并没有感到这是记录这些差异的首要任务。
我真正的意思是说：C库是否被POLICY认为是稳定的/有记录的Linux API，并且内核的系统调用API / ABI被认为是不稳定的（可能会改变），因此没有记录目的或低优先级？
那么更改系统调用的内核开发人员会在glibc中做出解决方法？ 那么其他libc呢？
我可以找到关于这个主题的历史讨论吗？
编辑：所以ABI是稳定的，也是系统调用的行为，但它们没有被内核开发者记录。 glibc正在记录它们（有自己的添加/更改）。 正确？
我不认为内核开发者会发布中断API，但你可以找到像这样的第三方图表。
你的问题的答案是在系统调用手册页。 特别要注意章节标题“架构调用约定”，并注意John Bollinger提到的上述内容，这些信息可能因内核版本而异。
我真正的意思是说：C库是否被POLICY认为是稳定的/有记录的Linux API，并且内核的系统调用API / ABI被认为是不稳定的（可能会改变），因此没有记录目的或低优先级？
没有明确说明谁的政策，对于什么，就不可能谈论政策。
编程“Linux”的人通常实际上是为一种或多种GNU / Linux编程，而不是为裸机编写内核。 因此，我倾向于说我们可能不考虑内核开发者策略。 事实上，如果C库接口完全可用，那么我们并不是在讨论裸核。 而且，根据你的标签，我假设你在问C编程。 如果你在汇编编程，那么原始的系统调用接口将是自然而恰当的，我的其余大部分评论都不适用。
如果你确实将GNU / Linux的目标排除在外，那么这个问题就有些明智了。 另一方面，通常情况下，人们更喜欢为更广泛的兼容性进行编程。 在这种情况下，使用C库系统调用接口确实没有其他选择，因为每个系统的原始系统调用都不相同。 Glibc的系统调用接口在符合POSIX和SUS方面做得很好，所以使用它们（适当地）对可移植性来说是一个巨大的优势。 即使其他Unix和类Unix系统（如OS X，BSD，Solaris等）不是直接的目标，也很难保证在此类系统上使用软件的可能性。
无论如何，如果您决定让您的软件直接执行Linux系统调用，那么您是否确实会插入内联汇编来随心所欲地执行该操作？ 当然不是 - 你会写包装功能。 那么，为什么您应该反对使用C库已经提供的全面测试和充分记录的封装函数？
当然，Linux系统调用接口在内核版本之间的确会有所变化。 这可以被认为是使版本不同的东西（我的意思是x.2y - > x.2z或xy - > zw ）。 我并没有很好地了解这种变化通常会有多大，但过去存在不兼容的变化，并且使用C库接口在某种程度上使您免受这些变化的影响。 然而，如上所述，我认为还有其他更喜欢C库接口的更多原因。