Talk:Linux kernel interfaces

Unnamed section
Hello. Does anyone now about the history of the Linux Kernel API? Where and when did it start? —Preceding unsigned comment added by Xparis (talk • contribs) 19:32, 6 October 2009 (UTC)


 * Of course! There are the and there also it The Linux Programming Interface by Michael Kerrisk User:ScotXW t@lk 11:48, 20 July 2014 (UTC)

Material

 * Single UNIX Specification/POSIX, latest version from December 2008 named SUSv4/POSIX.1-2008 defines (here) 1191 interfaces offered to programs by POSIX-conformant systems.
 * Theses "interfaces"/"facilities" are system calls, such as e.g. write, as well as functions present in GNU C Library
 * Conforming to http://man7.org/linux/man-pages/man2/syscalls.2.html the Linux kernel 3.9 had about 381 system calls, see also cgit
 * Conforming to http://www.gnu.org/software/libc/manual/html_mono/libc.html#Library-Summary the glibc 2.19 had about 1000 functions

The mentioned 381 system calls compose the system call interface (SCI). ScotXW (talk) 23:23, 18 February 2014 (UTC)

90.190.167.162 (talk) 14:18, 27 April 2014 (UTC) "People such as Lennart Poettering openly advocate writing software solely for the Linux kernel–user space API instead of POSIX" Even though I agree with that, that would require a reference.
 * Done, I only needed to copy it from his article. fosdem11 User:ScotXW t@lk 11:53, 20 July 2014 (UTC)
 * Not all interfaces in the SUS/POSIX are system calls. bsearch, for example, need make no system calls whatsoever, and printf, while it may need to make system calls to allocate buffers or write data to the output stream, does the core of its work - the formatting - in user mode.
 * That's why there are more SUS interfaces than Linux system calls. Guy Harris (talk) 09:28, 19 November 2023 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 2 external links on Linux kernel interfaces. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20150426153026/https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/stable_api_nonsense.txt to https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/stable_api_nonsense.txt
 * Added archive https://web.archive.org/web/20070227215533/http://www.gnugeneration.com/books/linux/2.6.20/kernel-api/ to http://www.gnugeneration.com/books/linux/2.6.20/kernel-api/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 13:40, 16 May 2017 (UTC)

Poettering? Really??
Wikipedia should not propagate an present as valid the biased unfounded views of people as infamous as Lennart Poettering, Alex Jones, Kim-Jong Un, etc. — 85.197.1.78 (talk) 21:34, 26 November 2017 (UTC)
 * Best comparison I've seen ever 47.156.233.252 (talk) 01:18, 28 February 2018 (UTC)

Inaccurate chart
Have these ever been discussed or addressed? Kroah-Hartman said one of the charts in this article is inaccurate - DFlhb (talk) 08:54, 29 November 2023 (UTC)

More clarifications needed about exact boundaries of APIs
I appreciate the efforts of article authors, who are apparently trying to explain a very complex state of affairs of Linux APIs. My view is that the common terminology in this field is confusing, and that is reflected in the article.

Consider this situation: A developer produces a binary of an OpenGL game.
 * 1) which APIs are supposed to be stable ones in that case?
 * 2) where is the supposed boundary of the OS?
 * 3) where is the supposed boundary of the Linux kernel?

The game binary is likely to load OpenGL as a shared library. There we have a stable interface between the game and the OpenGL shared library. This indidcates that the boudary of the OS is, in fact, at this interface.

The OpenGL shared library can be either Mesa or a proprieraty implementation. It is going to produce Linux syscalls to interact with the in-kernel OpenGL driver. The in-kernel OpenGL driver is a module, and the exact interface is unknown and unstable from the point-of-view of the developer who produced the game binary. There is nothing "stable" here between the kernel and the application, yet the article claims that some kind of stable API exists. The problem is in the imprecisely defined concepts of the OS and the Linux kernel. Where are the exact boundaries?

I think that the article should attempt to clarify this situation, which would make the article easier to understand. Z80Spectrum (talk) 20:03, 5 February 2024 (UTC)