Q： 为何linux在初始化过程中广泛使用__irpchip_of_table这种段基址来寻址硬编码的结构体变量，而不直接使用全局变量数组？

Linux 内核广泛使用 __irqchip_of_table 这类自定义段（Section）来存放硬件匹配结构体，而非全局数组，核心是为了模块化、可拔插、自动收集、可释放、跨文件无依赖—— 这是内核驱动与设备树（DT）匹配的核心设计思想。

下面从原理、对比、好处、实现细节四个层面讲透。

一、先看两种方式的本质区别

1. 全局数组方式（你说的 “直接用全局变量数组”）

// 假设全局数组硬编码
struct of_device_id irqchip_of_table[] = {
    { .compatible = "arm,gic-400",   .data = gic_of_init },
    { .compatible = "arm,cortex-a9", .data = gic_of_init },
    { .compatible = "ti,irq-gic",    .data = ti_irq_init },
    { /* 结尾空项 */ }
};

问题：

• 所有中断控制器必须集中写在同一个文件
• 增删驱动要修改全局数组，耦合极强
• 无法支持 ** 配置项（CONFIG_xxx）** 动态增删
• 内核初始化后无法释放这块内存

2. 段基址方式（内核实际用法：__irqchip_of_table）

每个驱动自己声明：

// drivers/irqchip/irq-gic.c
IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);

// drivers/irqchip/irq-ti.c
IRQCHIP_DECLARE(ti_gic, "ti,irq-gic", ti_irq_init);

宏展开后（简化）：

static const struct of_device_id __of_table_gic_400
__attribute__((__section__("__irqchip_of_table"))) = {
    .compatible = "arm,gic-400",
    .data = gic_of_init
};

链接脚本把同 section 变量自动合并成连续块，并给出起止符号：

__irqchip_of_table = .;
KEEP(*(__irqchip_of_table))  // 所有文件的__irqchip_of_table都收进来
__irqchip_of_table_end = .;

内核初始化时遍历段区间即可：

for (p = __irqchip_of_table; p < __irqchip_of_table_end; p++) {
    // 匹配设备树、调用初始化函数
}

二、为什么必须用段而不是全局数组（核心好处）

1. 完全解耦：跨文件、分布式声明，不需要集中维护

• 每个驱动 .c 自己声明自己的匹配表
• 不需要任何头文件 / 全局数组集中注册
• 增删驱动只增删自身文件，不改动任何公共代码
• 完美支持模块化、可配置（CONFIG_IRQCHIP_xxx）

2. 自动收集：链接器自动合并，内核零维护

• 只要用 __section__ 标记，链接器自动把所有同名段拼在一起
• 内核只需要知道段起止地址 __irqchip_of_table / __irqchip_of_table_end
• 不需要手动维护数组长度、结尾空项、顺序

3. 支持动态裁剪：CONFIG 开关直接生效

// 只有打开CONFIG_IRQCHIP_GIC才编译进内核
#ifdef CONFIG_IRQCHIP_GIC
IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
#endif

• 关闭 CONFIG → 整个结构体不编译、不占空间
• 全局数组做不到：必须运行时判断，内存依然占用

4. 初始化后可释放内存（关键！）

__irqchip_of_table 通常放在 .init.data 段：

.init.data : {
    ...
    IRQCHIP_OF_MATCH_TABLE()  // 放在init段
    ...
}

• 仅启动早期用到
• 初始化完成后，free_initmem() 整段释放
• 全局数组在 .rodata，永久占用内存

5. 多体系架构 / 多平台兼容

• ARM、RISC-V、MIPS 各自同名段独立定义
• 内核通用代码不用区分架构，统一遍历段即可
• 全局数组要大量 #ifdef 架构，代码混乱

6. 设备树匹配的天然模型

内核需要：

• 遍历所有可能的硬件匹配项
• 和设备树节点 compatible 字符串逐一匹配
• 找到后调用对应 .data 初始化函数

段方式天然提供：

• 只读、连续、可遍历的硬件描述表
• 完全符合 DT “先枚举所有支持，再按树匹配” 的模型

三、段 vs 全局数组：对比表

四、总结

Linux 用段基址而非全局数组，是为了实现 “分布式声明、链接器自动收集、配置化裁剪、初始化后释放、完全解耦” 的硬件描述模型 —— 这是设备树与内核驱动匹配的最优工程实践。

Q：还有比使用段基址方式保存硬编码变量更好的方式吗？

直接给你结论：

在嵌入式 / Linux 内核这种 “裸机 + 固件 + 静态链接” 场景下：没有比 “段基址方式” 更好、更通用、更优雅的方案了。

但！为了让你彻底理解为什么内核一定要这么做，我把所有能替代段基址的方案全部列出来，并告诉你各自的死穴。

你会瞬间明白：段基址 = 静态链接环境下的终极方案。

一、能替代段基址的 5 种方案（全给你排雷）

方案 1：全局数组

struct xxx table[] = { A,B,C,D };

死穴：

• 必须集中维护
• 不能跨文件自动注册
• 不能 CONFIG 裁剪
• 不能释放内存
• 耦合爆炸

结论：最差方案。

方案 2：运行时手动注册（initcall 里注册）

module_init(func);

驱动自己把结构体挂到链表上。

死穴：

• 必须在初始化阶段执行代码
• 异常、early init、irqchip 这种最早期初始化根本来不及
• 无法支持设备树遍历前就需要的硬件
• 无法释放内存

结论：不能用于最早期启动流程。

方案 3：动态链接（.so/ 模块）

用户态常用：插件机制。

死穴：

• 内核早期没有文件系统
• 没有动态加载器
• 嵌入式设备不可能用

结论：完全不适用。

方案 4：元数据 + 代码生成（像 DTS、protobuf）

编译前用脚本生成数组。

死穴：

• 破坏模块化
• 每个驱动改了都要重新生成
• 架构不清晰
• 内核不可能这么做

结论：工程上不可维护。

方案 5：段基址方式（内核真实使用）

__attribute__((section("__xxx_table")))

优点：

• 完全零耦合
• 分布式声明
• 自动收集
• 支持 CONFIG
• 初始化后可释放
• 最早期启动就能用
• 不执行代码就能遍历
• 链接器完成所有工作

结论：静态链接环境下的 ✅ 最优解。

二、为什么没有更好的？

因为：

1. 你想跨文件自动注册

→ 只有链接器能做到

2. 你想不执行代码就能枚举所有对象

→ 只有连续段（section）能做到

3. 你想支持 CONFIG 裁剪

→ 只有 section 能做到

4. 你想最早期启动（mmu 未开、中断未开）就能用

→ 只有 section 能做到

5. 你想初始化完释放内存

→ 只有 section 能做到

三、结论

在静态链接、无操作系统、无动态加载的环境下，段基址是唯一能实现 “跨文件自动注册、自动收集、零耦合、零运行时代码” 的技术。没有之一。 在 Linux 内核、ARM 嵌入式、Bootloader 这类场景： 段基址方式不是 “一种选择”，而是 “唯一正确的工程选择”。没有更好的，没有更现代的，没有更优雅的。**

• __irqchip_of_table
• __clk_of_table
• __pinctrl_of_table
• __device_of_table
• __initcall6_start

这些全部都是同一种设计模式。