[hkcat2007]

这个头那个头我头晕

[Joyfish]

看来，很多linux宣传文章所说的 “所有发行版都使用一个内核” 正在悄悄变质？
如果是真的，很讨厌这种情况。

[csfrank]

作者: Joyfish

看来，很多linux宣传文章所说的 “所有发行版都使用一个内核” 正在悄悄变质？
如果是真的，很讨厌这种情况。

嘿嘿，分久必合！
偶相信 make headers_install 将会一统江湖
目前各大发行版还没有一个能够占有绝对统治地位，因此也就没有一个敢于在分裂的道路上走的太远。
所以基本上可以认为商业发行版将会"若即若离"，而社区版本则会尽可能遵循统一的标准。
最终的结果估计还是会大一统或者接近大一统的。
在这一点上，偶觉得 BSD 做的很到位，非常到位！

[d00m3d]

作者: 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 以上版本的内核新特性(比如新的系统调用)和 API 的变化就无法反映出来，对于我们这些 DIY fans 来说，世界重回混沌……

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

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

说实在的，今天我还是没有搞懂那到底内核头文件为什麽要"净化"及"净化"了什麽。。。

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

[晨想]

我也不知道，不过看看 README 的内容：

README in llh:

The linux-libc-headers (llh) package (available at
http://ep09.pld-linux.org/~mmazur/linux-libc-headers/) contains headers
that export linux abi to userspace. These headers are a heavily modified and
cleaned up version of what comes with original linux tarball. See the FAQ
for more details.

Userland usefulness is achieved by removing kernel only parts (which often
generate errors) and using code provided by libc where possible (this allows
to avoid collisions when both linux and libc headers define the same structure
or constant). Unfortunately libc dependency might result in functionality loss
since libcs aren't always in sync with what kernel provides. If such a case
occurs please send a bug report to the maintainer (see AUTHORS file) and, if
possible, a workaround will be added. Do note that since llh is primarily for
2.6 based kernels we assume glibc to be at least version 2.3.3 (as far as I
know this version wasn't released officially but is being used by many current
linux distributions). Glibc is not a requirement though - llh is known to work
with other implementations of standard C library - but obviously is a
priority, so be prepared to send a bugreport if using something else.
In case you're wondering why take such an approach if it's obvious that it
might generate problems. Well, according to my knowledge there is consensus
among kernel hackers as to how userland headers should look like, but
unfortunately proper implementation (and wider adoption) will take time and
something that just plain works (in most cases anyway) is needed now.

[晨想]

LFS SVN 已经开始用 内核 提供的 内核头了。：）
http://www.linuxfromscratch.org/lfs/...x-headers.html

[d00m3d]

CLFS 的 SVN 仍未改过来，这回是 LFS 先行一步了

[晨想]

我的看法：LFS 没那么多人力去维护 LFS 的header工程，所以就转用 内核自带的头了。。嘿嘿。：）。

[d00m3d]

是这样吗，但今天为止 CLFS SVN 版里的内核仍停留在 2.6.20.1，比 LFS 还慢半拍啊

[晨想]

不知道了，也许内核太新，不能用在所有体系上吧。。

[very0717]

不懂是什么意思

[Vampire_Armand]

俺一直使用最古老的方法。
将内核源码树中的头文件直接复制到 /usr/include 中
那真的可以正常工作。

[MissBug]

有意思，休息休息，挺好～～～