内核、glibc 和用户空间答案

【问题标题】：kernel, glibc, and userland内核、glibc 和用户空间
【发布时间】：2013-01-09 23:21:37
【问题描述】：

我的目标是使用 debian（挤压）用户空间运行更新的内核 Linux 3.4。

Debian 的KernelFaq 只是说我们从 kernel.org 获取最新的原始内核并手动配置和编译它。

但是，在glibc documentation 中，它指出：

GNU C 库在比 [编译期间] 使用的内核头文件更早的内核上运行没有问题。反过来（使用旧内核头文件编译 GNU C 库并在最近的内核上运行）不一定能按预期工作。

由于内核 API 从 2.6.32 到 3.4 相当稳定，我可能只需要编译 3.4 内核就可以了；但是，我想知道这是否还会留下潜在的问题。

针对我的 Linux 3.4（或更高版本）头文件重新编译 eglibc 2.11.3-4 是否更正确？

【问题讨论】：

【解决方案1】：

我想知道这是否还会留下潜在问题。

你没有引用 glibc wiki 的下一段：

... 不一定按预期工作。例如，如果您使用旧的内核头文件来编译 GNU C 库，则不能使用新的内核功能。

换句话说，您现有的 glibc 构建（以及用户空间的其余部分）将在新内核上正常运行，但 glibc 可能不会使用内核提供的所有最新功能。 p>

【讨论】：

是的，但是对现有内核功能的更改/错误修复呢？这些更改是否会导致用户级应用程序出现意外行为？
我想得越多，我就越意识到这一点是没有意义的。针对新的内核头文件重新编译 glibc 不会改变内核实现。由于内核更改而中断的用户态应用程序是与内核不兼容的结果——而 glibc 与此无关。