摘要：本文深入剖析 Zephyr 设备模型的核心机制，完整追踪一个 Devicetree 节点从
DEVICE_DT_DEFINE()宏展开，到最终生成 ELF 中struct device对象的全过程。文章从struct device的四个核心成员（config、data、api、state）入手，逐步拆解DEVICE_DT_DEFINE()的宏调用链，阐明 Device Symbol、Config/Data/API 分离设计、Init Entry、Dependency Handle 等关键概念，并厘清dependency ordinal与init priority的本质区别。最后通过简化版手撕示例和 ELF 符号验证，帮助读者建立从源码到固件的完整认知，为将公司 SoC 接入 Zephyr 打下坚实基础。
从 DEVICE_DT_DEFINE() 手撕 struct device 的生成
TL;DR（太长不看版）
DEVICE_DT_DEFINE()是设备对象生成器，不是简单的struct device初始化，它向下调用DEVICE_DT_DEINIT_DEFINE()→Z_DEVICE_DEFINE()，最终生成 Device Object、Config、Data、API 和 Init Entry 五个部分。（见第三、四、十七节）DEVICE_DT_GET()在编译期解析为&__device_dts_ord_xx，通过 Devicetree 宏直接取符号地址，不是运行时搜索设备。（见第七、八节）- Config / Data / API 三者分离：config 是静态硬件配置（ROM/RO），data 是运行时状态（RAM），api 是驱动操作接口（RO），
struct device只是持有这三个指针的中心节点。（见第九～十三节） - Init Entry 与 Dependency Handles 是两条隐藏链：Init Entry 把初始化函数按 level + priority 放进 linker section，由 boot 阶段统一执行；Dependency Handles 记录设备间的依赖关系，用于设备排序与访问控制。（见十四～二十节）
dependency ordinal≠init priority：前者回答"设备在依赖图中的身份编号"，后者回答"初始化阶段何时执行"，两者最终在设备初始化系统中汇合。（见二十一节）
这一篇我们不再停留在：
“Zephyr 有一个 struct device。”
而是直接回答：
一个 DTS 节点，究竟是如何一步一步变成最终 ELF 里的 struct device 对象的？
核心目标是把这条链彻底打通：
DTS │ ▼ DT_NODELABEL(uart0)│ ▼ DEVICE_DT_DEFINE(...)│ ▼ DEVICE_DT_DEINIT_DEFINE(...)│ ▼ Z_DEVICE_DEFINE(...)│ ├── struct device ├── device_config ├── device_data ├── driver API ├── init entry └── dependency handles │ ▼ 最终 ELF │ ▼&\__device_dts_ord_xx │ ▼ struct device *一、先看最终目标：我们到底想生成什么？
假设 Devicetree：
&usart1{status="okay";current-speed=<115200>;};然后 driver 中写：
DEVICE_DT_DEFINE(DT_NODELABEL(usart1),uart_stm32_init,NULL,&uart_data,&uart_config,PRE_KERNEL_1,CONFIG_SERIAL_INIT_PRIORITY,&uart_driver_api);最终我们希望得到一个类似这样的对象：
structdevice__device_dts_ord_XX={.name="usart1",.config=&uart_config,.api=&uart_driver_api,.data=&uart_data,.state=...,};但这里有一个非常重要的认知：
你在源码中通常不会直接看到这样一个完整的 struct device 初始化器。
因为 Zephyr 用了大量宏，把它拆成多个编译期对象。
二、先回顾 struct device
Zephyr 的设备模型核心就是：
struct device概念上可以简化成：
structdevice{constchar*name;constvoid*config;constvoid*api;void*data;structdevice_state*state;};不同 Zephyr 版本的具体字段可能有所变化，所以这里重点不是字段数量，而是理解：
struct device │ ├── config │ ├── data │ ├── api │ └── state其中：
config
硬件的静态配置：
structuart_stm32_config{uintptr_tbase;...};通常放在只读区域。
data
运行时数据：
structuart_stm32_data{...};通常位于 RAM。
api
driver 对外暴露的操作：
staticconststructuart_driver_apiuart_driver_api={.poll_in=...,.poll_out=...,...};state
Zephyr 自己管理的 device state。
例如：
device initialized device initialization failed device power state三、真正关键的宏
现在进入核心。
你看到：
DEVICE_DT_DEFINE(...)不要把它理解成：
struct device xxx;
而应该把它理解成：
一个"设备对象生成器"。
四、第一层：DEVICE_DT_DEFINE()
概念上可以理解成：
#define DEVICE_DT_DEFINE(node_id, init_fn, pm, data, config, level, prio, api, ...)它实际上会继续向下调用更底层的宏。
典型结构可以抽象成：
DEVICE_DT_DEFINE()│ ▼ DEVICE_DT_DEINIT_DEFINE()│ ▼ Z_DEVICE_DEFINE()│ ├──────────────┐ ▼ ▼ struct device dependency handles注意：
真正值得研究的是 Z_DEVICE_DEFINE()。
五、为什么不能直接写 struct device？
假设我们自己写：
