Linus discussion on the relationship between kernel header files and kernel source code

Source: Internet
Author: User
Tags symlink
Linus discusses the relationship between kernel header files and kernel source code-Linux general technology-Linux programming and kernel information. The following is a detailed description.
CODE: From: Linus Torvalds (torvalds@transmeta.com)
Date: Thu Jul 27 2000-02:39:51 EST

In article ,

Boszormenyi Zoltan Wrote:
>
>/Usr/include/asm is a symlink to/usr/src/linux/include/asm, as in
> Original distribution but/usr/src/linux is a 2.4.0-testX tree.
> With a 2.2.X source tree, it does not produce any warning.


I 've asked glibc maintainers to stop the symlink insanity for the last
Few years now, but it doesn't seem to happen.


Basically, that symlink shoshould not be a symlink. It's a symlink
Historical reasons, none of them very good any more (and haven'tbeen
For a long time), and it's a disaster unless you want to be a C library
Developer. Which not very between people want to be.


The fact is, that the header files shoshould match the library you link
Against, not the kernel you run on.


Think about it a bit .. Imagine that the kernel introduces a new "struct
X ", and maintains binary backwards compatibility by having an old system
Call in the old place that gets passed a pointer to "struct old_X ".
It's all compatible, because binaries compiled for the old kernel will
Still continue to run-they'll use the same old interfaces they are
Still used to, and they obviously do not know about the new ones.


Now, if you start mixing a new kernel header file with an old binary
"Glibc", you get into trouble. The new kernel header file will use
_ New _ "struct X", because it will assume that anybody compiling against
It is after the new-and-improved interfaces that the new kernel
Provides.


But then you link that program (with the new "struct X") to the binary
Library object archives that were compiled with the old header files,
That use the old "struct old_X" (which _ used _ to be X), and that use
Old system call entry-points that have the compatibility stuff to take
"Struct old_X ".


Boom! Do you see the disconnect?


In short, the _ only _ people who shoshould update their/usr/include/linux
Tree are the people who actually make library releases and compile their
Own glibc, because if they want to take advantaged of new kernel
Features they need those new definitions. That way there is never any
Conflict between the library and the headers, and you never get warnings
Like the above ..


> Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard
> "Don't use kernel headers directly" answer. But neither gcc. c,
> Neither the above small program use kernel headers. I suppose he
> Referred to/usr/include/linux/* as (I think) he did not understand me.


No. He really meant that you shoshould not use the kernel headers: you
Shocould use the headers that glibc came with. It is probably a redhat bug
That those headers were a symbolic link.


I wocould suggest that people who compile new kernels shold:


-NOT do so in/usr/src. Leave whatever kernel (probably only
Header files) that the distribution came with there, but don't touch
It.


-Compile the kernel in their own home directory, as their very own
Selves. No need to be root to compile the kernel. You need to be root
To _ install _ the kernel, but that's different.


-Not have a single symbolic link in sight (could not the one that
Kernel build itself sets up, namely the "linux/include/asm" symlink
That is only used for the internal kernel compile itself)


And yes, this is what I do. My/usr/src/linux still has the old 2.2.13
Header files, even though I haven't run a 2.2.13 kernel in a _ loong _
Time. But those headers were what glibc was compiled against, so those
Headers are what matches the library object files.


And this is actually what has been the suggested environment for
Least the last five years. I don't know why the symlink business keeps
On living on, like a bad zombie. Pretty much every distribution still
Has that broken symlink, and people still remember that the linux
Sources shocould go into "/usr/src/linux" even though that hasn' t been
True in a _ loong _ time.


Is there some documentation file that I 've not updated and that people
Are slavishly following outdated information in? I don't read
Documentation myself, so I 'd never notice ;)


Linus
Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.