c++如何读取Linux内核生成的Device Tree二进制流【深度】-C++-PHP中文网

用户态应优先通过/proc/device-tree伪文件系统读取设备树，因其以目录树形式暴露节点和属性，无需解析二进制；若需原始dtb则用libfdt解析，避免手写解析器或依赖不可靠路径。

c++如何读取linux内核生成的device tree二进制流【深度】

Linux用户态如何解析内核加载的`dtb`文件

内核启动时加载的dtb（Device Tree Blob）通常已解压并展开为运行时结构体（struct device_node），**用户态无法直接访问这些内核内存数据**。想读取设备树内容，必须从源头入手：要么读取启动时传入的原始dtb二进制文件，要么通过/proc/device-tree这个由内核自动导出的伪文件系统。

常见错误是试图用mmap去映射/sys/firmware/devicetree/base或/proc/device-tree的某个节点——它们是只读、无长度的特殊文件，stat()返回st_size == 0，read()才有效。

/proc/device-tree是首选：它按目录树结构暴露所有节点和属性，无需解析二进制格式，兼容所有主流内核（>=3.10）
若需原始dtb（比如做签名验证或离线分析），得确认启动介质中是否保留了该文件（如U-Boot环境变量fdt_addr_r指向的地址、或initramfs里的/dtb）
不要依赖/sys/firmware/devicetree/base：它在部分ARM64平台不可见，且某些发行版默认未挂载

用C++递归遍历`/proc/device-tree`提取节点信息

这是最轻量、最可靠的方式。每个子目录对应一个device node，每个普通文件对应一个property，文件内容即property值（可能含\0，需用read()而非fgets）。

关键点：

用opendir()/readdir()遍历目录，跳过"."和".."
对每个条目调用stat()判断类型：S_ISDIR()进子节点，S_ISREG()读property值
property值**不以\0结尾**，长度需用st_size获取；字符串类property（如compatible）末尾有\0，但二进制property（如reg）是raw字节流
路径深度影响可读性，建议用栈或递归控制缩进，避免硬编码层级

示例片段（读取/proc/device-tree/cpus/cpu@0/compatible）：

int fd = open("/proc/device-tree/cpus/cpu@0/compatible", O_RDONLY);
struct stat st;
fstat(fd, &st);
std::vector<uint8_t> buf(st.st_size);
read(fd, buf.data(), st.st_size);
// buf[0]...buf[st.st_size-1] 即原始字节
close(fd);
</uint8_t>

用libfdt解析原始`dtb`文件（需链接`libfdt`）

当必须处理原始二进制dtb（例如从flash dump中提取、或与内核启动参数校验一致性），libfdt是事实标准。它被dtc、u-boot等广泛使用，头文件为<fdt.h></fdt.h>，函数前缀统一为fdt_。

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

典型流程：

用fdt_open_into()或fdt_load()加载完整dtb到内存（注意：dtb必须是完整、未截断的二进制流）
用fdt_first_subnode() + fdt_next_subnode()遍历子节点
用fdt_getprop()读取property：返回指针指向内部buffer，**不能free，且生命周期仅限于fdt blob存活期**
property长度由lenp参数传出，务必检查返回值是否为NULL（表示property不存在）

易错点：

fdt_check_header()必须在任何操作前调用，否则非法dtb会导致段错误
fdt结构体本身不管理内存，fdt buffer需全程保持有效（不能是栈变量或被realloc移动）
多线程下需加锁：libfdt不是线程安全的，同一fdt实例不能并发访问

为什么不用`libdevicetree`或自己写解析器

libdevicetree（非主流）缺乏维护，API不稳定；手写解析器风险极高——dtb格式包含magic、totalsize、off_dt_struct、off_dt_strings等偏移字段，且存在版本差异（v17/v18）、对齐要求（8字节）、字符串表引用机制。哪怕跳过校验，仅正确识别node/prop边界也容易越界读。

真实场景中，95%的需求靠/proc/device-tree就能满足；剩下5%（如bootloader调试、firmware签名校验）才需要libfdt。强行绕过这两个路径，大概率在fdt_next_tag()循环里卡死或读出乱码。

真正难的从来不是“怎么读”，而是弄清你要的数据在哪一层：是启动时传给内核的原始描述，还是内核解析后生成的运行时视图，抑或是驱动实际看到的platform_device资源——三者语义不同，不能混用。