[八卦故事]内核头文件传奇

csfrank

做 LFS 是不是很累了？OK，让我先来讲一段八卦故事，放松放松神经，然后再继续冒险吧。。。

在 Linux 2.2/2.4 的纯真年代，内核头文件一直保持着 Unix 世界的"KISS"传统，只需将内核源码树中的头文件直接复制到 /usr/include 中即可使用，一切都是那么 Simple and Stupid ...

但是随着 2.6 系列内核的发布，事情开始变得混乱和复杂起来。首先是内核开发者宣布强烈反对直接使用"未净化"的"原始"内核头文件，他们建议使用发行版提供的"经过净化的"内核头文件。于是各种发行版开始"八仙过海，各显神通"，由于"净化"方法各不相同，结果就是每个发行版都有着自己与众不同的内核头文件。更为严重的是，内核开发者甚至推荐编译 Glibc 的头文件也要使用发行版提供的"经过净化的"内核头文件。由于 Glibc 和 Kernel 是整个系统的根基，这样一来 Linux 便像传统的 Unix 那样开始走向分裂。

另一件哭笑不得的事情是，虽然内核开发者强烈推荐使用发行版提供的"经过净化的"内核头文件，但是 Glibc 的开发者却不买账，他们推荐使用"未净化"的"原始"内核头文件来编译 Glibc ，两个开发组一直坚持各自的见解，互不妥协！另外，两个开发组在应当由谁提供内核头文件的问题上意见也不一致：内核开发组认为应当由发行版的制作者提供，而 Glibc 开发组认为应当由内核开发组提供。结果就是"神仙打架，凡人遭殃"，虽然对 Debian 这种大型发行版来说，提供自己独有的"经过净化的"内核头文件不会成为多大的负担，但是对于那些没有能力或精力的小心发行版制作者和我们这些 DIY fans 来说却是一场灾难！要么直接使用其他发行版的成果，要么自力更生；前者让人心有不甘(没有了 DIY 的原汁原味)，后者让人望而生畏(有几个人知道啥叫"净化"?怎么净化?)。

危机时刻总会有英雄的出现，就在一片恐慌之际，一个叫"linux-libc-headers"项目组诞生了！他们向我们这些"凡人"们提供了安全的、普遍适用的、"经过净化的"内核头文件，真是及时雨啊！天空重新晴空万里……然而好景不长，由于精力和人力有限，该项目在发布了 2.6.12.0 版本之后，遗憾的离开了这个世界。这样一来，2.6.12 以上版本的内核新特性(比如新的系统调用)和 ABI/API 的变化就无法反映出来，对于我们这些 DIY fans 来说，世界重回混沌……

俗话说，"合久必分，分久必合"，大概是内核开发组意识到了如果继续固执己见将不可避免的导致混乱以及重蹈 Unix 逐渐走向分裂的覆辙，于是从 2.6.18 版本开始，内核开发组担负起了维护一份统一的、"经过净化的"内核头文件的职责(窃以为这原本就是他们的责任)。现在获取"经过净化的"内核头文件又变得简单起来，只要在内核源码树中使用 make headers_install 即可，而且不用再担心更新问题。对于我们这些 DIY fans 来说，又可以重新 Day Day Happy 了。

不过，由于磨合需要时间。目前 Glibc-2.4 以下的版本都无法配合这种新式头文件编译成功。不过偶相信前途一片光明……

VirusCamp

原来现在这样做了啊！

make headers_install

huohuliaisili

坐着板凳听故事。
最喜欢听故事了。

鸟无音信

哈  有意思

晨想

写的好，虽然我都知道，但是要写成故事偶还是做不到，没那水平的说。
make headers_install 的确不错，至少感觉比较 genuine 的说。glibc 2.5 我试过，没问题。

（我的观点，这玩意本来就是应该内核提供的，因为他叫 内核头。活活。）

youbest

恩，现在变的简单了，不过了解一下过去挺有意思。

rickxbx

我有个问题, 如果使用某个发行版,比如 debian, 他有自己"经净化"的头文件放在 /usr/include 下.现在我要做一件事, 自己下载一份最新的内核的 souce, 这个source 是从kernel.org 上下的, 然后编译, 如果最后 make headers_install  的话, 那以前的"内核头"岂不是会被覆盖掉? 如果不 make headers_install  的话, 那么使用新的内核的时候, 却使用老的"内核头"会不会有问题?

btw: 很喜欢这种描写历史发展的文章

whitelilis

关注中。。。
长见识了。。。。

csfrank

不建议自动覆盖以前的内核头，而是手动彻底删除原来的内核头(rm -fr /usr/include/{asm,linux})，之后再安装新的内核头。
根据 Glibc 的 FAQ ，编译 Glibc 时使用的内核头文件版本可以比实际运行 Glibc 的内核版本高。比如用于编译 Glibc 的内核头文件版本为 2.6.22 ，但是实际运行 Glibc 的可以是 2.6.16 版本的内核(编译 Glibc 时必须使用 --enable-kernel=2.6.16 而不能使用 --enable-kernel=2.6.22 )。允许这样做的好处是即使将来把内核升级到 2.6.22 也不需要重新编译 Glibc 了。另一方面，如果实际运行的内核版本比头文件版本高，那么新内核的新特性(主要是系统调用)将无法使用。
不过自己升级内核头(不使用发行版提供的头)的话，还是很危险的，保险的做法是把系统从Glibc开始全部重新编译一遍，不过这样一来你的Debian还是Debian吗？
这也就是为什么内核头不统一将会导致Linux走向分裂的原因。

rickxbx

Post by csfrank
比如用于编译 Glibc 的内核头文件版本为 2.6.22 ，但是实际运行 Glibc 的可以是 2.6.16 版本的内核(编译 Glibc 时必须使用 --enable-kernel=2.6.16 而不能使用 --enable-kernel=2.6.22 )。允许这样做的好处是即使将来把内核升级到 2.6.22 也不需要重新编译 Glibc 了。

内核升级到 2.6.22 以后还是要重新编译 glibc 的吧? 不需要用 --enable-kernel=2.6.22 编译一下吗?