【发布时间】:2016-12-03 15:52:47
【问题描述】:
这个问题是关于配置维护和测试的。
如果使用不当,#ifdef, #ifndef, #elseif, #elif, #else, #endif 预处理器指令不仅会降低 C 代码的可读性和可维护性,而且还会增加回归错误的风险(例如,当特定的构建配置在一段时间内没有经过测试时)时间)。
我想知道 linux 内核如何能够维护大量的配置选项而不会陷入完整的维护地狱?
我知道这对于各种不同的硬件都具有灵活性是必要的,但是对于应用程序开发人员来说,配置选项的数量之多真的让我感到害怕。
您认为以下哪些陈述是正确的?
- 大多数供应商只为其目标平台使用一组标准配置,因此大多数可能的配置组合既没有经过测试也没有使用
- 存在非常严格的编码准则,仅允许为明确可分离的代码段引入新的
#ifdef's,在这些代码段中禁用某个功能(以及负责做出这些决定的合适人员)是有意义的 - 每个新内核版本都有如此多的测试人员,以至于配置相关的错误得到及时修复,因为其中大多数可能只是构建回归
【问题讨论】:
-
缺少选项:(*) 只允许明智的人决定放入什么以及如何放入。
-
我不是回答这个问题的专家,但我可以预见配置主要选择哪些文件进入和退出构建。如果您构建到架构 X,那么所有其他架构都将被排除在构建之外。
-
我不认为这只是关于架构和整个驱动程序,因为确实存在用于无数低级功能的配置选项
-
我会注意到您询问的两个问题(可读性与可测试性)是不同的问题,并且一些补救措施是不同的。对于可测试性问题,IIRC Ingo Molnar 倾向于让一些机器编译大量“make randconfig”配置,因此在 LKML 上搜索 randconfig 可能会提供一些见解,有关可读性,请参阅 SubmittingPatches 第 2 节,题词 2。
-
您的问题有点含糊,让您很难确切地知道什么。您是在谈论用于构建内核的配置文件还是?如果你能提供一个例子就好了。
标签: linux linux-kernel c-preprocessor configure maintenance