这个问题是关于配置维护和测试的。
如果使用错误，#ifdef, #ifndef, #elseif, #elif, #else, #endif预处理器指令不仅会降低C代码的可读性和可维护性，而且还会增加回归错误的风险（例如，特定构建配置尚未针对特定构建配置进行测试时）一段时间）。
我想知道linux内核如何能够维护大量的配置选项而不会遇到完全的维护地狱？
我知道这对于各种不同的硬件都是灵活的，但是作为应用程序开发人员，配置选项的数量绝对令我感到非常可怕。
您认为以下哪项陈述属实？
#ifdef's，其中禁用某个功能（以及负责做出这些决定的合适人员）是有意义的编辑：我意识到有测试机器可以选择随机配置并检查它们是否构建和启动。但是，这些简单的构建/启动测试无法检测到除了破坏所有内容的错误之外的任何严重回归
答案 0 :(得分：2)
我正在直接使用Linux内核和“Das u-boot”。到目前为止，我没有足够的经验，但我会试一试。
据我所知，您所谈论的配置文件实际上是由多个文件组成的，从大多数常见的东西，如CPU架构等，到非常详细的东西，如RAM频率等等。
是的，这是非常的，我的意思是非常可怕，但正如你所说，非常好（至少是体面的文档）项目必须继续。此外，你必须意识到有大量人在处理那里的所有东西。当然，没有人能够认为自己是所有的真正鉴赏家。
不是100％肯定，但我认为你是对的，大多数供应商至少使用一些标准配置。例如，假设大多数智能手机具有相同的通用硬件架构（CPU，GPU，RAM等），因此无需自定义所有内容。
同样是的，主要代码充满了
#ifdef, #ifndef, #elseif, #elif, #else, #endif
这显然有它的优点和缺点。但这是关于C（和C ++）的美妙事物之一，它允许控制一切。有时退出授权，有时候是真正的噩梦。
没有任何关于测试的内容：）
答案 1 :(得分：1)
Linux项目及其Kernal Maintenence使用与其他开源软件处理配置管理的不同方面相同的框架。
以这种方式维护内核有三个要素：创建存储库，更新和维护它，并将其集成到构建基础结构中。
但Linux架构差异通常在模块中处理，日志注释通常作为历史记录读取，描述文件的开发方式。
每个版本的代码都在一个单独的目录中，并将贡献和补丁应用于“最新”目录。捐款 只能由主持人应用于存储库。创建新版本时，最新版本将复制到新版本中 即使开发仍在继续，也要发布目录以保存它。
这就是为什么你通常会在Linux内核开发中看到两个分支 - 一个稳定版本分支和一个开发分支的原因。