[arch-general] linux-api-headers in core is 3.1.5 while linux is 3.1.6
Right now I've noticed the following: linux-api-headers 3.1.6-1 linux 3.1.7-1 Maybe is my little understanding of the situation, but isn't linux-api-headers behind what it (appears to me that it) should be? I apologize in advance if the question turns to be dumb or something like that. -- Alex
Am 05.01.2012 16:01, schrieb Alex Ferrando:
Right now I've noticed the following:
linux-api-headers 3.1.6-1 linux 3.1.7-1
Maybe is my little understanding of the situation, but isn't linux-api-headers behind what it (appears to me that it) should be?
I apologize in advance if the question turns to be dumb or something like that.
The linux-api-headers package is entirely unrelated to the running or installed kernel. It contains the headers that give glibc the API to the Linux kernel, and must never (NEVER NEVER NEVER) be different from the version that glibc was built against. Please, someone give me a cent for every time this question is asked.
Please, someone give me a cent for every time this question is asked. If I ever go to Germany, I'll buy you enough beers to last you through
On 01/05/2012 10:26 PM, Thomas Bächler wrote: the night. :P
Maybe is my little understanding of the situation, but isn't linux-api-headers behind what it (appears to me that it) should be?
The linux-api-headers package is entirely unrelated to the running or installed kernel. It contains the headers that give glibc the API to the Linux kernel, and must never (NEVER NEVER NEVER) be different from the version that glibc was built against.
Please, someone give me a cent for every time this question is asked.
It may help if this information is in an easily reachable area, as I couldn't find it anywhere after searching the wiki and forums followed by the internet as a whole. The closest thing that I found was from LFS, but this actually makes it seem like it is very closely bound to both kernel and glibc. -Patrick
On 06/01/12 18:00, Patrick Buddeberg wrote:
Maybe is my little understanding of the situation, but isn't linux-api-headers behind what it (appears to me that it) should be?
The linux-api-headers package is entirely unrelated to the running or installed kernel. It contains the headers that give glibc the API to the Linux kernel, and must never (NEVER NEVER NEVER) be different from the version that glibc was built against.
Please, someone give me a cent for every time this question is asked.
It may help if this information is in an easily reachable area, as I couldn't find it anywhere after searching the wiki and forums followed by the internet as a whole. The closest thing that I found was from LFS, but this actually makes it seem like it is very closely bound to both kernel and glibc.
On Fri, Jan 6, 2012 at 00:12, Allan McRae
On 06/01/12 18:00, Patrick Buddeberg wrote:
Maybe is my little understanding of the situation, but isn't linux-api-headers behind what it (appears to me that it) should be?
The linux-api-headers package is entirely unrelated to the running or installed kernel. It contains the headers that give glibc the API to the Linux kernel, and must never (NEVER NEVER NEVER) be different from the version that glibc was built against.
Please, someone give me a cent for every time this question is asked.
It may help if this information is in an easily reachable area, as I couldn't find it anywhere after searching the wiki and forums followed by the internet as a whole. The closest thing that I found was from LFS, but this actually makes it seem like it is very closely bound to both kernel and glibc.
Thank you. I derped and didn't check the Newbie Corner but only the Kernel section. And of course I am just now reading "If no forums are selected, all forums will be searched." I failed pretty hard there. Is there somewhere anyone would recommend for getting a more in-depth understanding of why the API header can be divorced from the kernel. Honestly, even a "Let Me Google that For You" link would be useful to my mental blocked self right now. My guess is that there is an internal symbol table that the API headers uses, and that they also don't necessarily support the newest things in the kernel, if there are new things that are being exposed. Thank you, -Patrick "If you tell me that curiosity killed the cat, I say the cat died nobly" Arnold Edinborough
On Jan 6, 2012 9:52 PM, "Patrick Buddeberg"
Honestly, even a "Let Me Google that For You" link would be useful to my mental blocked self right now.
http:// http://lmgtfy.com/?q=sanitized+kernel+headers+stable+libc+abi lmgtfy.com http://lmgtfy.com/?q=sanitized+kernel+headers+stable+libc+abi /?q=sanitized+kernel+headers+stable+http://lmgtfy.com/?q=sanitized+kernel+headers+stable+libc+abi libc http://lmgtfy.com/?q=sanitized+kernel+headers+stable+libc+abi+http://lmgtfy.com/?q=sanitized+kernel+headers+stable+libc+abi abi http://lmgtfy.com/?q=sanitized+kernel+headers+stable+libc+abi ;-) http:// http://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.html lkml.indiana.eduhttp://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.html / http://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.htmlhypermailhttp://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.html /linux/kernel/0007.3/0587.http://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.html html http://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.html [ http:// http://lwn.net/Articles/434318/lwn.nethttp://lwn.net/Articles/434318/ /Articles/434318/ http://lwn.net/Articles/434318/ ] "The most common way to invoke the kernel is by using GNU libc (glibc). Glibc has a set of "sanitized" kernel header files that are used to build the library, and distributions typically provide packages with those header files to be installed into /usr/include. Programs can then be built by using those header files and linking to glibc. While "sanitized" may sound like it refers to the removal of GPL-covered elements from those files, the main reason it is done is to remove kernel-specific elements from the files. The kernel headers have lots of kernel-internal types, constants, and functions that are not part of the kernel interface. It isn't really correct to call the interface that the kernel provides to user space an API (i.e. application programming interface), as it is really an application binary interface (ABI), and one that the kernel hackers strive to maintain for each new kernel release. Removing something from the kernel ABI almost never happens, though new features expand that ABI frequently. The ABI is what allows binaries that were built on an earlier kernel to run on newer kernels. The API, on the other hand, is provided by glibc or some other library." (kernel can generate its own sanitized headers since 2.6.18) ... so in my understanding, glibc can take advantage of new kernel features simply by being rebuilt -- when you invoke syscalls/etc from userspace, you call them THRU the libc library -- libc can do whatever behind the scenes to make use of additional features other user space programs are unaware of, so long as the expected return types match. Without this, binaries would break all the time because the perceived API would be in constant flux, even though the ABI is back-compat ... all of user space looks to glibc to access kernel, so the API files update when glib updates, and do not correlate with the actual kernel in-use (please anyone expand/correct as needed ... my knowledge is only ~30 min old) C Anthony [mobile]
Thank you. -Patrick
participants (6)
-
Alex Ferrando
-
Allan McRae
-
C Anthony Risinger
-
Patrick Buddeberg
-
Smith Dhumbumroong
-
Thomas Bächler