📚 课程目录第3章 drm_info核心数据结构

3. drm_info 核心数据结构：drm_device、drm_file、drm_minor 的内部关联

在 DRM 子系统中，drm_device、drm_file 和 drm_minor 是三个最核心的数据结构，它们共同构成了显示驱动与用户空间交互的骨架。理解这三者的内部关联，是解析 drm_info 输出、定位驱动性能瓶颈的基础。

3.1 核心数据结构概览

下表从角色、生命周期、所属层级三个维度，快速对比这三个结构体：

数据结构	角色描述	生命周期	所属层级
`drm_device`	代表一个物理或虚拟显示设备，是 DRM 子系统的顶层对象	设备驱动加载时创建，卸载时销毁	内核驱动层
`drm_file`	代表用户空间进程打开 DRM 设备后的文件私有数据	进程调用 `open()` 时创建，`close()` 时销毁	内核文件层
`drm_minor`	代表一个 DRM 设备节点（如 `/dev/dri/card0`）	设备注册时创建，注销时销毁	内核设备模型层

调试提示： 在 drm_info 输出中，drm_device 对应的是 "Device" 段落的全局信息，drm_file 对应的是 "Clients" 段落中每个进程的上下文，而 drm_minor 则隐含在 "Nodes" 或设备路径信息中。

3.2 三者的层级关联与指针网络

这三个结构体通过双向指针形成了一张紧密的关联网络。下图展示了它们之间的核心引用关系：

3.3 drm_device：显示设备的“大脑”

drm_device 是 DRM 驱动中最大的结构体，它聚合了驱动所有的全局状态。在 drm_info 的 "Device" 段落中，你看到的驱动名称、版本、能力标志、IRQ 信息等，都来自这个结构体。

  关键字段速览：
  struct list_head filelist —— 挂载所有打开此设备的 drm_file 实例链表
struct drm_minor *primary —— 指向主设备节点（通常用于 modeset）
struct drm_minor *render —— 指向渲染节点（用于 GPU 计算）
struct drm_driver *driver —— 指向驱动回调函数表
struct drm_mode_config mode_config —— 显示模式配置的根对象

3.4 drm_minor：设备节点的“门面”

每个 drm_minor 对应一个 /dev/dri/ 下的设备节点。系统中有三种类型的 minor：

类型	设备节点路径	主要用途	drm_info 中的体现
DRM_MINOR_PRIMARY	`/dev/dri/card0`	显示控制（modeset）、page flip、GEM 操作	"Nodes" 段落中的 card 节点
DRM_MINOR_CONTROL	`/dev/dri/controlD64`	权限受限的控制节点（已逐渐废弃）	较少出现
DRM_MINOR_RENDER	`/dev/dri/renderD128`	纯 GPU 渲染/计算，无需 modeset 权限	"Nodes" 段落中的 render 节点

drm_minor 内部维护了指向 drm_device 的反向指针 minor->dev，以及一个关键链表 minor->list，用于将自身挂入 drm_device 的全局 minor 列表。

3.5 drm_file：用户空间进程的“身份令牌”

每当用户空间进程调用 open("/dev/dri/card0")，内核就会创建一个 drm_file 实例。这个结构体记录了该进程的权限、已分配的 GEM 对象、提交的 fence、以及当前的 DRM 上下文。

// 内核源码 include/drm/drm_file.h (简化示意)
struct drm_file {
    struct drm_minor        *minor;         // 所属的设备节点
    struct drm_device       *dev;           // 通过 minor->dev 间接访问
    struct pid             *pid;            // 进程 PID
    struct list_head        lhead;          // 挂入 drm_device->filelist
    unsigned long           magic;          // 认证魔法值
    struct drm_master       *master;        // 主控权限对象
    struct idr              object_idr;     // 本进程的 GEM 对象句柄表
    struct list_head        fbs;            // 本进程创建的 framebuffer 列表
    // ... 更多字段
};

性能调试要点： drm_file 中的 object_idr 是 GEM 句柄到内核对象的映射表。当 drm_info 显示某个客户端有大量 GEM 对象时，意味着该进程可能没有及时释放不再使用的 buffer，这是内存泄漏的常见信号。

3.6 三者的运行时关联流程

下面这张流程图展示了从用户空间 open() 到内核建立完整关联的过程：

3.7 在 drm_info 输出中识别三者关系

当你运行 drm_info 时，可以通过以下对应关系快速定位这三个结构体的信息：

drm_info 输出段落	对应的内核结构	关键输出示例
Device	`drm_device`	`Driver: i915, Version: 1.6.0, IRQ: 132`
Nodes	`drm_minor`	`Primary: /dev/dri/card0, Render: /dev/dri/renderD128`
Clients	`drm_file`	`PID: 1234 (Xorg), GEM objects: 256, Fences: 3`

实战技巧： 当调试显示异常时，先检查 drm_info 的 "Clients" 段落。如果某个 drm_file 的 GEM 对象数量异常增长，而 "Device" 段落的全局对象计数也同步增长，说明该进程存在 buffer 泄漏。此时可以通过 cat /sys/kernel/debug/dri/0/gem_names 进一步确认是哪些 buffer 没有被释放。

3.8 总结：三者的协作模式

drm_device 是全局唯一的硬件抽象，drm_minor 是设备节点的具体呈现，drm_file 是每个用户空间连接的生命周期载体。三者通过以下模式协作：

自上而下： drm_device 通过 primary 和 render 指针管理 drm_minor，通过 filelist 链表管理所有 drm_file。
自下而上： drm_file 通过 minor 指针找到 drm_minor，再通过 minor->dev 找到 drm_device，完成从用户空间 fd 到内核全局设备的完整寻址。
横向关联： 同一个 drm_device 下的所有 drm_file 通过 filelist 串联，方便内核进行全局遍历（如 drm_info 的 "Clients" 列表生成）。