内核头文件为什麽要"净化"？

d00m3d

我花了一点点时间重温 LFS 手册，想到一个问题不太明白，LFS 手册第5章编译 glibc 前说安装 linux-libc-headers 的原因是为了提供一个"净化过"(sanitized)的内核头文件，而且不主张用内核源文件内的头文件

到第8章完成编译内核之後又强调净化过的内核头文件要对应编译 glibc，不要用源码包内的头文件来取缔

那到底内核头文件为什麽要"净化"？"净化"了什麽？

youbest

我也搞不大清楚,不过看了一下CLFS的做内核头的代码觉得并没有对内核的头文件做什么本质的更改,只不过合并了一些头文件,我现在就在用内核提供的头文件做系统,目前只发现一处问题,其它还没发现什么不对劲的地方.
我也想知道为什么要"净化"?难道内核提供的头文件太乱?

d00m3d

youbest 在做 CLFS 了？发现了什麽问题？问题是否跟没净化的 header 有关？

youbest

没有在做CLFS,最近还在攻关Olive上的一些问题,只是以前幻想同志给的一个CLFS的关于header的地址看了一下上面的脚本.
最近遇到的一个问题,我个人觉得是2.6.16内核自带的头文件的一个Bug,但不能确定,因为最新的内核也没有更改这个地方.

晨想

收集一点资料：

1. http://www.diy-linux.org/x86-reference-build/introduction.html

We are compiling Glibc against sanitized kernel headers ie: the `linux-libc-headers' package. Compiling Glibc against raw kernel headers is always an option, but it goes against the Glibc developer's general advice of recent times to use distro-supplied sanitized headers. As of kernel-2.6, sanitized kernel headers are the only realistic option for installation into /usr/include because the raw headers are pretty much unusable when installed there.

2. http://www.linuxfromscratch.org/ ... /files/OLD/nptl.txt

6. Sanitized kernel headers

   It is agreed that user space shouldn't use kernel headers, but a
   set of sanitized headers such as distributions use instead. In
   addition to it not being kosher, stock kernel headers in /usr/include
   will break a lot of packages due to changes in 2.6 kernels. Get the
   latest Fedora headers from:

     http://download.fedora.redhat.co ... /development/SRPMS/

   The package name is glibc-kernheaders-*. You can use rpm2cpio to first
   convert and extract it. All you'll need is glibc-kernheaders.tar.bz2.
   I've also made the tarball available in http://ttervo.vectorstar.net/nptl,
   but don't expect it to be the latest one available. In the same directory,
   you'll also find POSIX compliancy patches for several packages (see notes
   after chapter 5 Glibc instructions).

3. http://ep09.pld-linux.org/~mmazur/linux-libc-headers/doc/FAQ

Q: When compiling $INSERTYOURAPP I got an error message saying I shouldn't
   be including kernel only files.
A: The llh package is for providing userland interfaces. It doesn't contain
   internal kernel definitions. If you get such an error you most likely need
   to fix your app either not to include offending files or to search for
   headers inside kernel sources.
   If you believe your sources are correct mail the maintainer (check AUTHORS
   file for his address) to clear the matter up.

4.http://lists.debian.org/debian-glibc/2003/11/msg00069.html
虽然在LKML里边我没找到相应的说明，但是我觉得没必要去找了。

5. http://headers.cross-lfs.org/ 和 http://headers.cross-lfs.org/browser
LFS 大本营的东西，当然要看看咯。：）。


我认为与其讨论为什么需要 净化，不如讨论一下 如何净化，或者 LFS 书上有什么可以改进的东西。

d00m3d

看完以上的连结，综合的结论就是

1. 使用净化过的 header 就少问题
2. 内核自带的 header 是"混浊"的，容易出问题
3. 用户自行编译软件所用的 header 必需是对应编译 glibc 时用的 header

没有交待净化了什麽，该如何净化呢？

常言 glibc 不宜朝乱升级，看来 header 也不能乱动的了。。。

晨想

1. 理论上是这样的。至少净化头的作用就是这个。
2. 恩。
3. 是的。当年[color="Red"]好像流行 /usr/include 的东西都是直接拷贝 Kernel的，每次升级也跟着升。不应该这么做。

至于如何净化，我看比八仙过海还精彩，每个发行版都有自己的一套净化方法，仁者见仁，智者见智。。。CLFS 也有自己的方法，我也贴出了地址，里边的 header 脚本，就是净化脚本。

herader一直都不要乱来的咯，glibc还可以动，不过也会引起大的变动，比如全局重新编译等。嘿嘿。：）。。

hans_yu

看了半天，没有全部明白，有点晕

大概理解了这么几点，不知道对不对：
1. glibc主要提供用户空间的程序执行， kernel的头文件相当于内核空间向用户空间提供的窗口
2. 由于这个窗口比较大，内核中的一些东西也就暴露出来了。这是由于内核头文件的定义有时不可避免的定义了一些内核空间的常数、接口函数。
3. 本来内核空间和用户空间的程序互不干扰，即使有相同的定义也不影响。但由于内核的东西在头文件这个窗口中暴露了出来，就会引起glibc的编译错误
4. 所以有人建立一个工程，将内核头文件的内容仔细过滤，将不该用户空间看见的东西全部隐藏了起来
5. 提供了glibc比较稳定的API接口，不会因为内核内部的变动，使得glibc也需要重新编译

等待各位朋友的鲜花或鸡蛋

ppluer

各位讨论的问题我也很关心
但是水平有限 很多地方理解不了

按照lfs的文档安装了Linux-Libc-Headers后
LFS文档不建议创建/usr/src/linux指向内核原码目录
那么可否将它指向Linux-Libc-Headers 所在的目录？--/usr/include

我在vmware里安装lfs
如果不安装vmware tools得不到高分辨率的支持
但是在安装tools过程中他会不停的要匹配的头文件
所以我有了上面的想法 不知道这样能否满足vmware的需求

晨想

直接用内核的头就好了，没必要弄什么 symlink