问题描述
系统调用有 man(2) 页，但这些页描述了位于系统调用之上的 C 库 (glibc) 的行为.原始系统调用 API/ABI 是否记录在某处(UseTheSourceLuke 除外)?我在手册页中看到了一些关于 kernel/libc 之间差异的提及，但我没有感觉到记录这些差异是首要任务.
There are man(2) pages for the system calls, but these describe the behavior of the C library (glibc) that sits on top of the system calls. Is the raw system call API/ABI documented somewhere (other than UseTheSourceLuke)? I saw some mention of differences between kernel/libc in the man pages, but i did not get the feeling that it is a top priority to document these differences.
我真正想说的是:C 库是否被 POLICY 认为是稳定/记录的 Linux API，而内核的系统调用 API/ABI 被认为是不稳定的(可能会改变)，因此故意未记录或低优先级?
What i really mean to say is: Is the C library considered to be the stable/documented Linux API by POLICY, and the system call API/ABI of the kernel is considered unstable (may change) and therefore undocumented on purpose or low priority?
那么更改系统调用的内核开发人员可以在 glibc 中找到解决方法吗?那么其他 libc 呢?
So kernel developers that change a system call make workarounds in glibc? What about the other libc's then?
我能找到关于这个主题的历史讨论吗?
Can i find historical discussions about this subject?
所以 ABI 是稳定的，系统调用的行为也是如此，但内核开发人员没有记录它们.glibc 正在记录它们(带有自己的添加/更改).正确吗?
So the ABI is stable, and also the behavior of syscalls, but they are not documented by kernel developers. The glibc is documenting them instead (with its own additions/changes). Correct?
推荐答案
我不认为内核开发者实际上发布了中断 API，但是你可以找到像 这个.
I don't think the kernel developers actually post the interrupt API, but you can find third-party charts like this one.
这篇关于是否有原始的 linux 系统调用 API/ABI 文档的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！