当前位置：首页 → 问答吧 → 对内核头文件的理解

对内核头文件的理解

时间：2008-12-09

来源：互联网

编译 glibc 之前要安装内核头文件，编译内核之后要保持原有的内核头文件，而不用新的内核源码中的头文件。这样才能确保互为依赖的 libc 和内核完全正常的(理论上的，实际上多少会因 bug 而不能及)协同工作。
若 libc 和内核使用不同的头文件，则当应用程序以其一为据编译，调用另一方不支持的特性时，必会出错。应用程序多与 libc 打交道，所以应当以 libc 所依赖的标准为依据，也就在是 libc 编译后要保留其所依赖的头文件供应用程序所用。
内核头文件才是 Linux 的真正标准，不仅 libc 要以此为据，内核(使用，非编译)也要以此为准。内核较新时就要委屈内核，不让其发挥新特性。
所谓“净化”也就是把仅在内核内部各部分间使用的接口剔除，只留下供外部使用的公开接口。libc 也就是以此公开接口为标准编译，所有的应用程序也应当是。“净化”过的内核头文件就是绝对标准。
YY ，哈哈！

作者: ch_fb 发布时间: 2008-12-09

恩我也是这样理解的~~

作者: lofeng410 发布时间: 2008-12-09

谢谢了，不过还是不太明白，要学的东西还有很多。

作者: tlze 发布时间: 2008-12-09

可惜我的2.6.28-rc7内核头文件太新，装不上LFS-6.4中的kbd软件。
不过这个软件好像也没什么用。

作者: ti8er 发布时间: 2008-12-09

引用:

作者: ti8er

不过这个软件好像也没什么用。

似乎记得X中、gnome中有些包依赖它

作者: newper 发布时间: 2008-12-10

楼主有误导大众嫌疑。

引用:

作者: ch_fb

编译 glibc 之前要安装内核头文件，编译内核之后要保持原有的内核头文件，而不用新的内核源码中的头文件。这样才能确保互为依赖的 libc 和内核完全正常的(理论上的，实际上多少会因 bug 而不能及)协同工作。

linux-kernel 仅依赖硬件和 gcc部分特性。

libc 应用于绝大部分现代系统，与其配合使用的内核绝不仅限于 linux-kernel，其需要的仅是内核头文件提供的平台相关信息。
libc 的历史比 linux-kernel 久的多，找些 glibc 的历史读读会很有帮助的。
另，libc 也绝不止一种，linux系统下可用的有 glibc、uclibc、newlib。

引用:

作者: ch_fb

若 libc 和内核使用不同的头文件，则当应用程序以其一为据编译，调用另一方不支持的特性时，必会出错。应用程序多与 libc 打交道，所以应当以 libc 所依赖的标准为依据，也就在是 libc 编译后要保留其所依赖的头文件供应用程序所用。

是有可能出错，不能编译，或者编译成功、运行时出错，或者不出错。
不同版本的 linux-kernel 有可能提供仅版本号定义不同的头文件。

引用:

作者: ch_fb

内核头文件才是 Linux 的真正标准，不仅 libc 要以此为据，内核(使用，非编译)也要以此为准。内核较新时就要委屈内核，不让其发挥新特性。

这是笑话，无恶意，理由见偶关于 linux-kernel 的描述。

引用:

作者: ch_fb

所谓“净化”也就是把仅在内核内部各部分间使用的接口剔除，只留下供外部使用的公开接口。libc 也就是以此公开接口为标准编译，所有的应用程序也应当是。“净化”过的内核头文件就是绝对标准。
YY ，哈哈！

用户空间程序没有任何理由直接使用内核头文件，仅应使用 glibc、libstdc++ 提供的系统头文件，所谓的“净化”只是为了提供一套稳定的内核头文件给 glibc，使其不必跟着 linux-kernel 的升级而升级，这个读读 glibc 的历史会有帮助。
当前版本的 linux-kernel 提供的已是“净化”过的头文件。

作者: 聚焦深空发布时间: 2008-12-12

虽然现在头文件能从内核源码直接提取，可是我是未搞懂"净化"是做了什麽动作

http://www.linuxsir.org/bbs/showthread.php?t=260766

深空兄可有提示否？

作者: d00m3d 发布时间: 2008-12-14

从非开发者角度考虑，其实没必要关心内核头文件“净化”问题。
毁灭兄给出的链接、还有楼主的部分叙述已说明“净化”问题。

早期的 GNU/Linux 系统使用的是一份独立维护的 libc (libc5)，在 glibc-2.0 (libc6) 发布后又合并到一起，见：
http://en.wikipedia.org/wiki/GNU_C_L...temporary_fork

曾经有一段时间，每当 linux-kernel-header 有变化，libc 就要做相应调整，反过来也一样，这对于维护者来说是噩梦，于是有必要维护一份长时间相对稳定的 linux-kernel-header，具体的过程就是“净化”——删除一切用户空间不需要的信息。
安装内核头文件之后，和 linux-kernel 源代码 include 目录下原始的内核头文件比较一下，就可以了解“净化”的过程。

当前的 glibc 由于要运行在多种硬件平台、多种系统，其对 linux-kernel-header 的依赖较早期时要少得多。

作者: 聚焦深空发布时间: 2008-12-14

要麽去"净化"的问题是很早便明白了，但"净化"了什麽却不是很清楚

作者: d00m3d 发布时间: 2008-12-14

前一阵看了youbest老大的clfs原理分析，就有这个疑问。

文章中提到的内核头文件是直接拷贝过去用的。

现在我把这个疑问重新提一下：
文章中没有说明配置内核与编译交叉工具链的先后顺序（我想这可能是个低级问题，我是初学者，就请见谅啦）。

我想应该是先
make ARCH=arm menuconfig
然后才能使用内核头文件吧，不管是通过直接拷贝，还是用make header_install来得到纯净的内核头。

不知以后理解是否有错？

如果不错的话，也会有个问题：
针对嵌入式环境，自己裁剪linux内核，定制高度专用化的内核的情况可能比较多吧，比如为了缩小体积，我的应用程序不使用IPC机制相关的功能的话，我完全可以把相应的支持拿掉吧？

如果我上面的理解无误，那岂不是针对每一次裁剪的linux内核，都要相应编译一套它专用的工具链？大家知道，编译工具链是个挺痛苦的过程啊。

作者: true_log 发布时间: 2008-12-14

引用:

作者: d00m3d

要麽去"净化"的问题是很早便明白了，但"净化"了什麽却不是很清楚

这个读读代码会很清楚的，说不太清，或者是偶表达能力有限。

引用:

作者: true_log

文章中没有说明配置内核与编译交叉工具链的先后顺序（我想这可能是个低级问题，我是初学者，就请见谅啦）。

先后顺序无关的。前提是在开始行动后，您不能修改内核源代码。

引用:

作者: true_log

我想应该是先
make ARCH=arm menuconfig
然后才能使用内核头文件吧，不管是通过直接拷贝，还是用make header_install来得到纯净的内核头