Kernel header file legend

Kernel header file legend-general Linux technology-Linux programming and kernel information. For more information, see the following section. In the pure Linux 2.2/2.4 era, the kernel header file has always maintained the "KISS" tradition in the Unix world. You only need to copy the header file in the kernel source code tree to/usr/include for use, everything is so Simple and Stupid...

But with the release of the 2.6 series kernel, things began to become chaotic and complex. First, kernel developers announced strong opposition to directly using the "unpurified" "original" kernel header file. They suggested using the "purified" kernel header file provided by the release. As a result, various Release versions start to "go across the sea and show their advantages". Because the "purification" methods are different, the result is that each release has its own unique kernel header file. More seriously, kernel developers even recommend that you use the "purified" kernel header file provided by the release version to compile Glibc header files. Because Glibc and Kernel are the foundation of the entire system, Linux starts to split like traditional Unix.

Another thing to laugh at is that, although kernel developers strongly recommend using the "purified" kernel header file provided by the release, Glibc developers do not buy it, they recommend that you use the "unpurified" "original" kernel header file to compile Glibc. The two developers have always insisted on their own opinions and do not compromise with each other! In addition, the two development teams have different opinions on who should provide the kernel header file: the kernel development team believes that it should be provided by the producer of the release, while the Glibc development team believes that it should be provided by the kernel development team. The result is "fairy fights, Mortal suffering". Although for large releases such as Debian, providing their own unique "purified" kernel header files won't become much of a burden, but it is a disaster for those who are not capable or energetic to be careful with the release creators and our DIY fans! Either directly use the results of other releases, or be self-reliant; the former makes people unwilling (without the original flavor of DIY ), the latter is daunting (how many people know it as "purification "? How to purify ?).

There will always be heroes in crisis times. Just as a panic arises, a "linux-libc-headers" project team is born! They have provided us with secure, universally applicable, and "purified" kernel header files to our "mortal" people. It's really time and rain! A clear sky ...... However, due to limited energy and manpower, the project left the world after 2.6.12.0 was released. In this way, the new kernel features (such as new system calls) and ABI/API changes of 2.6.12 and later versions cannot be reflected. For our DIY fans, the world is back to chaos ......

As the saying goes, "a combination of time is required, and a combination of time is required", probably because the kernel development team realized that if they continue to stick to their opinions, it will inevitably lead to chaos and repeat the same time that Unix is gradually splitting, since version 2.6.18, the kernel development team has been responsible for maintaining a unified, "purified" kernel header file (which is originally their responsibility ). Now it is easy to get the "purified" kernel header file, as long as you use make headers_install in the kernel source code tree, and there is no need to worry about updates. For our DIY fans, we can have a new Day Happy.

However, it takes time to break in. At present, versions below the Glibc-2.4 can not be combined with this new header file compiled successfully. But I believe that the future is bright ......