kbuild 与设备树相比如何?

kbuild 与设备树相比如何?

我知道 KConfig 用于在 Linux 内核编译开始时调整 C 预处理器。设备树用于在运行时为编译后的内核提供有关硬件的描述。

这两个可配置功能如何重叠?

例如,两者都提供有关内部 CPU 详细信息和外部外围设备驱动程序的信息。我想设备树中提到的任何外设都必须获得先前在 .config 文件中声明的驱动程序。我也可以猜测,如果驱动程序已编译为内置驱动程序,它将不会再次作为模块加载......但是有哪些更详细的细节呢?

答案1

编译时内核配置可以指定是否包括内核源代码树中包含的每个标准驱动程序,如何这些驱动程序将被包含在内(作为内置或可加载模块),以及一些其他参数与编译内核时将使用哪种优化和其他选择相关(例如针对特定 CPU 型号进行优化,或尽可能通用,或者是否默认启用某些功能,例如 Spectre/Meltdown 安全缓解措施) )。

如果编译时内核配置设置得足够通用,则同一内核可以与同一处理器架构内的大量不同系统一起使用。

另一方面,设备树与内核当前运行的实际硬件有关。对于嵌入式系统和其他没有自动探测技术(如 ACPI 或 PCI(e))的系统,设备树将指定精确的 I/O 或内存地址特定的硬件组件将在以下位置找到,以便驱动程序能够找到并使用这些硬件组件。

即使设备树描述了特定硬件组件的存在以及如何访问它,如果在编译时禁用了它所需的驱动程序,那么内核将无法使用它,除非稍后单独添加驱动程序模块。或者,如果内核是使用完全整体配置编译的,没有可加载模块支持,那么该内核将根本无法使用特定设备,除非该设备的驱动程序包含在内核编译中。

如果硬件组件的驱动程序包含在内核配置中(内置或作为可加载模块),但设备树中没有它的信息(并且硬件体系结构不包括标准检测机制),则内核将不知道硬件组件的存在。例如,如果设备树错误地将显示控制器的帧缓冲区区域指定为常规可用 RAM,那么您可能会随机显示存储在显示控制器的默认帧缓冲区区域中的任何字节,作为混乱的像素“噪声”。或者,如果显示控制器需要特定的初始化才能开始工作,您可能根本不会得到任何输出。

换句话说,设备树的目的是告诉内核系统的各种硬件功能位于处理器地址空间中的位置,既使内核能够将正确的驱动程序指向正确的物理硬件,又使内核能够将正确的驱动程序指向正确的物理硬件。告诉内核它应该使用地址空间的哪些部分不是尝试将其用作常规 RAM。

相关内容