【问题标题】:How does the linux kernel maintain the vast amount of config options?linux内核如何维护大量的配置选项?
【发布时间】: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


【解决方案1】:

我自己直接使用 Linux 内核和“Das u-boot”。到目前为止,我还没有足够的经验,但我会试一试。

据我所知,您所说的配置文件实际上是由多个文件组成的,从 CPU 架构等最一般的东西到 RAM 频率等非常详细的东西。

是的,这非常,我的意思是非常令人恐惧,但正如您所说,项目必须继续进行(至少是体面的文档)。此外,你必须意识到有大量的人在处理那里的所有东西。当然,没有人可以认为自己是一切的真正鉴赏家。

不是 100% 肯定,但我认为大多数供应商至少使用一些标准配置是正确的。例如,假设大多数智能手机具有大致相同的通用硬件架构(CPU、GPU、RAM 等),因此无需完全自定义所有内容。

也对,主要代码满满的

#ifdef, #ifndef, #elseif, #elif, #else, #endif

这显然有它的优点和缺点。但这是关于 C(和 C++)的美妙之处之一,它允许控制 一切。有时放弃授权,有时是一场真正的噩梦。

关于测试没什么可补充的:)

【讨论】:

    【解决方案2】:

    Linux 项目及其内核维护使用与其他开源软件处理配置管理不同方面相同的框架。

    以这种方式维护内核需要三个要素:创建存储库、更新和维护它,以及将其集成到构建基础架构中。

    但 Linux 的架构差异通常在模块中处理,并且 log cmets 通常被读取为历史记录,描述文件是如何发展的。

    每个版本的代码都在一个单独的目录中,并将贡献和补丁应用到“最新”目录。贡献 只能由版主应用到存储库。创建新版本时,会将最新版本复制到新版本中 发布目录以保存它,即使开发继续。

    这就是为什么您通常只会在 Linux 内核开发中看到两个分支的原因——一个稳定发布分支和一个开发分支。

    【讨论】:

    • 主分支少总是一个优势,但它没有解释如何针对回归测试所有这些配置
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2022-06-26
    • 2016-03-25
    • 1970-01-01
    • 2016-01-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多