Is there raw linux system call API/ABI documentation
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.
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?
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?
Edit: 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，但你可以找到像这样的第三方图表。
The answer to your question is in the syscall man page. Particularly pay attention to the section title "Architecture calling conventions" and note as mentioned by John Bollinger above that this information could vary among kernel versions.
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?
It's impossible to speak to policy without specifying whose policy, for what.
People programming for "Linux" typically are in fact programming for one or more flavors of GNU / Linux, as opposed to for the bare kernel. I'm therefore inclined to say that we're probably not considering kernel developer policy. Indeed, if the C library interface is available at all then we're not talking about a bare kernel. Moreover, based on your tagging, I'm supposing you're asking about C programming. If you were programming in assembly then the raw syscall interface would be natural and appropriate, and most of the rest of my comments would not apply.
If you are indeed targeting GNU / Linux to the exclusion of anything else, then the question is somewhat sensible. On the other hand, it is often the case that one would prefer to program for broader compatibility. In that case, there really is no alternative to using the C-library syscall interfaces, because each system's raw syscalls are different. Glibc's syscall interfaces do a pretty good job of conforming with POSIX and SUS, so using them (properly) is a tremendous advantage for portability. Even if other Unix and Unix-like systems, such as OS X, BSD, Solaris, etc. are not immediate targets, it is rarely a loss to hold open the possibility of using your software on such systems.
Anyway, if you were determined to have your software execute Linux syscalls directly, then would you indeed insert inline assembly to do that everywhere you wanted it? Surely not -- you would write wrapper functions. Why, then, should you object to using the thoroughly tested and well-documented wrapper functions already provided by the C library?
Certainly the Linux syscall interface does change to some extent between kernel versions. That can be considered the thing that makes versions different (I mean x.2y -> x.2z or xy -> zw ). I'm not well tuned in to how large such changes typically are, but there have been incompatible changes in the past, and using the C library interfaces insulates you from such changes to some extent. As described above, however, I think there are other, larger reasons for preferring the C library interface.
上一篇: nasm系统调用Linux