九边深夜跑一个推理任务，看着 nvidia-smi 里GPU利用率跳来跳去，相信很多搞AI的兄弟都想过一个问题：PyTorch调一个 cuda()，到底是怎么让GPU真正算起来的？而一旦在WSL里看到 failed to initialize nvml: gpu access blocked by the operating system，或者在Windows里弹窗“显示器驱动已停止响应并已恢复”，大部分人第一反应是“驱动坏了重装”，很少有人会去想：究竟是哪一层代码在决定这些症状？
这一层代码，就是GPU KMD（Kernel Mode Driver，内核模式驱动）。
KMD是操作系统内核中负责管理和驱动GPU硬件的那段程序。它不像CUDA那样活跃在应用层，也不像显卡驱动安装包那样只负责“装完能用”。它是一个常驻内核态的管家，代表整个系统协调所有进程对GPU的使用。这篇文章是零基础学GPU KMD系列的第一篇，我会把它到底是谁、处在哪个位置、日常管哪些事、出了问题怎么认出来，以及零基础学习该从哪里入手，一次性讲透。不管你是想搞GPU驱动开发的工程师，还是只想知道AI训练底层到底怎么回事的开发者，这篇都能帮你把地基打牢。
1. 一次AI推理任务背后，KMD都干了什么
先说一个反直觉的结论：在GPU上跑一次最简单的矩阵乘法，整个链路里KMD做的事，比你想象的多得多。
以现在最常见的LLM推理为例。你在终端敲下 python run_inference.py，模型权重加载到显存，然后开始一个token一个token地生成。这条命令背后是一条完整的调用链：
- Python脚本调用PyTorch的生成接口
- PyTorch的CUDA后端调用
cublas、cudnn这类算子库 - 算子库进入用户态驱动，最常见的是Linux下的
libcuda.so - 用户态驱动把API请求翻译成GPU硬件能理解的指令流，准备好参数缓冲区
- 通过
ioctl系统调用进入内核态 - KMD接手，做显存分配、页表设置、命令入队、通知硬件开工这一整套动作
- GPU执行完毕后触发中断
- KMD处理中断，唤醒正在等待结果的应用线程
- 应用拿到输出，继续跑下一个token
这九步里，第6步和第8步是KMD的主场，但第5步之前用户态驱动也离不开KMD提前给它登记好的设备节点。换句话说，你写的每一行CUDA代码，最终的“临门一脚”都是KMD帮你踢出去的。
用生活化的方式理解：用户态驱动像一个业务员，跟客户接洽、整理订单、把需求写得清清楚楚；KMD则是后勤主管加仓库管理员加保安队长——它要验收订单，分配仓库货架（显存），盯着员工干活（调度GPU计算单元），员工干完了还得喊你取货（中断通知）。
这里有个很关键的问题：如果干脆没有KMD，让每个应用直接访问GPU寄存器，行不行？
行，但只能活一个进程。假设第一个进程直接操作GPU寄存器把活儿干了，第二个进程也想这么干，它怎么知道现在GPU是不是正在被第一个进程用？进程A往显存地址0x1000写了自己的隐私数据，进程B读同一个地址，是不是直接读到别人家的东西？再往严重了说，进程C把GPU频率调到极限，导致整卡过热烧毁，算谁的？
这些问题的根源在于：GPU是一个被整个系统共享的硬件资源。共享资源需要有人统一管理，而这个“统一管理”的职责，天然属于操作系统内核，也就是KMD。这也是为什么没有哪个正常操作系统会把GPU硬件直接暴露给用户态进程。
顺便说一句，很多人第一次感受到KMD的存在，恰恰是通过报错。在WSL2里跑 nvidia-smi 遇到 gpu access blocked by the operating system，这个报错从字面上就很有意思：操作系统把你的GPU访问给拦了。拦你的不是某个应用，不是你的代码，而是内核态这一层的授权机制。WSL2里的GPU支持本质上是通过虚拟化GPU（GPU-PV）实现的，guest系统里的驱动要访问宿主机的GPU，必须经过宿主机KMD这一层“代理授权”。KMD没准备好，或者guest与host的驱动组件版本不匹配，你的GPU请求就直接被拒之门外。这就是KMD在真实环境里刷存在感的最典型场景之一。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. KMD在软件栈里的确切位置：它夹在谁和谁之间
想要彻底搞懂KMD的定位，最好的办法是把一整套GPU软件栈画出来，然后看清楚每一层在干什么。
下面这张图是Linux下最常见的GPU软件栈结构（Windows下类似，只是名字不同）：
code复制应用层： PyTorch、游戏、Blender、Ollama
API层： CUDA、OpenGL、Vulkan、DirectX
用户态驱动： libcuda.so、amdgpu用户态、Mesa
系统调用： ioctl / mmap / open / close
内核态驱动： KMD（Linux下通常是DRM驱动，如amdgpu、i915、virtio-gpu）
硬件层： GPU核心、显存、显示输出、视频编解码器
KMD在Linux里的载体通常是DRM（Direct Rendering Manager）驱动。AMD的开源驱动叫 amdgpu，Intel的叫 i915（新一代是 xe），NVIDIA闭源驱动的内核模块也注册了一个DRM驱动，叫 nvidia-drm。在Windows下，KMD要按WDDM（Windows Display Driver Model）规范来实现，微软从WDDM 1.0一路迭代到现在的WDDM 3.x，每一版都在加强内存管理、虚拟化和硬件调度能力。
这里必须回答一个根本问题：为什么需要“内核态”这一层，不能全部放用户态吗？
答案可以从三个维度拆开看。
第一，安全与隔离。用户态进程天然不可信，但GPU硬件资源不能因为某个进程乱来就崩溃。KMD负责给每个进程建立独立的GPU地址空间，设置页表权限，确保进程A永远碰不到进程B的显存数据。这个过程需要操作硬件MMU页表，这个动作只有在内核态才能可靠地完成。否则随便一个进程都能读取别人的显存，AI时代最看重的数据隐私就是一句空话。
第二，全局协调。GPU是被整个系统共享的。当一个游戏和一个训练任务同时跑在同一个GPU上，必须有角色站在全局视角调度，决定这两个进程谁拿多少计算单元、谁的优先级更高、谁能占多少显存。用户态驱动只看到自己那一亩三分地，它没有全局视野，也不应该被赋予这种权力。KMD就是这个“带着全局视野做决策”的角色。
第三，异步硬件事件。GPU执行完任务之后是通过中断通知CPU的。中断属于内核事件，只有内核态的驱动能处理。处理完中断之后唤醒对应的用户态进程，这也是内核的看家本领。如果靠用户态轮询GPU状态，一是延迟高，二是浪费CPU，三是压根不知道什么时候该轮询。
用户态驱动和KMD的分工，可以用一句话概括：用户态负责“高频、简单、翻译性质”的活儿——把API调用变成GPU指令流，这块慢了最多影响单个进程；KMD负责“低频、关键、决策性质”的活儿——资源分配、调度、隔离、中断，这块错了就是全体崩坏。
还有一点值得澄清：很多人会把“显卡驱动”跟KMD划等号。实际上，一套完整的GPU驱动栈至少包含五部分：安装器、用户态库、内核态驱动、固件/微码、管理工具。你平时装的NVIDIA驱动包里，其实同时包含了用户态的 libcuda.so、内核态的 nvidia.ko、以及 nvidia-smi 这类管理工具，外加一票固件。KMD只是这五部分之一，但它是其他所有组件能正常工作的地基。这就好比一栋楼里，用户态库是各个房间的装修，KMD是承重墙——装修再好看，承重墙塌了整栋楼都得完。
3. 拆解KMD的核心职责：六件你会反复碰到的事
从功能上看，KMD日常要管的事可以拆成六块：命令提交与调度、显存管理、中断处理、电源与热管理、上下文管理与虚拟化、以及与内核其它子系统的对接。下面逐一说清楚。
3.1 命令提交与GPU调度
用户态驱动把任务翻译成GPU指令流之后，怎么把它交给GPU硬件？
现代GPU普遍采用“共享队列”机制。用户态驱动把命令写进一块内存缓冲区（称为ring buffer），然后通过写一个特定的MMIO寄存器（称为doorbell，门铃）来通知GPU“有新任务，可以来取了”。KMD在这一步负责的是维护队列的完整性——它要确认命令缓冲区合法、命令格式正确、权限足够，然后把新命令的尾部指针推进硬件可见的位置，最后敲响门铃。
门铃机制听起来简单，但调度策略很复杂。GPU硬件层面上，一个GPU里有几十上百个计算单元（NVIDIA叫SM，AMD叫CU），这些单元可以被多个上下文共享。KMD的调度器要决定：当前有多个进程的命令队列在排队，谁先执行？执行多久？能不能抢占？
举个最常见的场景：你在打游戏，游戏画面渲染依赖GPU，而后台有个AI训练任务正在贪心地把GPU算力吃满。如果没有KMD的调度，训练任务可能导致游戏帧率掉到没法玩的程度。KMD的调度器会按照优先级和时间片把GPU计算资源切分开，保证游戏画面不被饿死。这不是“尽量优化”，而是KMD真正的本职工作。
3.2 显存管理
显存（VRAM）是KMD管的最宝贵的资源。现在一张高端显卡的显存从24GB到80GB不等，但跟系统内存动辄上百GB相比还是紧巴巴的。更何况大模型训练和推理对显存的需求是几十GB起步。
KMD在显存管理上做三件事。第一是分配与释放：当用户态驱动通过 cudaMalloc 申请显存时，底层调用的是KMD的显存分配接口。第二是地址映射：GPU有自己的一套MMU，KMD要给每个上下文建立独立的GPU页表，让GPU虚拟地址能正确映射到物理显存，同时完成进程间隔离。第三是回收与碎片整理：显存不够用的时候，KMD要尝试回收那些可以释放的页面，处理显存碎片，实在不行才返回分配失败。
你肯定见过PyTorch报 CUDA out of memory。这个报错的本质是KMD尝试了各种办法（换页、回收牺牲页、检查是否有空闲块）之后，依然没能满足分配请求，于是向上返回一个“内存不足”的错误。理解了这一层，你就能明白为什么有时候明明 nvidia-smi 里显示还有几个GB显存，但代码还是会OOM——因为显存碎片化了，找不出一个足够大的连续块来满足你的分配请求。这个坑我在实际训练里踩过不止一次，后面有机会专门写一篇展开。
3.3 中断处理与完成通知
GPU执行命令是异步的：CPU把任务提交给GPU之后，GPU在后台自己跑，CPU可以去做别的。GPU跑完之后，怎么让CPU知道？
答案是中断。现代GPU用MSI-X中断机制，GPU完成任务后向CPU发送一个中断信号。KMD的中断处理程序分两段：上半部（top half）快速响应对硬件进行确认，清理中断状态；下半部（bottom half）在安全上下文中执行，唤醒等待该任务的用户态进程，更新任务完成状态。
中断处理的延迟直接影响端到端的推理性能。如果KMD的中断处理写得拖沓，GPU完成一个请求后CPU半天才响应，整个推理链路的吞吐量就会被拖垮。这就像快递员摁了门铃，结果保安隔了五分钟才出来开门——快递到了也没用，效率损耗在中转站。
3.4 电源与热管理
GPU是所有消费级硬件里最耗电的部件之一，一张旗舰显卡的功耗轻松超过300W，AI加速卡甚至能到700W。这些热量散不出去，硬件分分钟烧给你看。
KMD的电源管理核心是DVFS（动态电压频率调整）。它根据GPU实时的负载、温度、功耗数据，动态调整核心频率和电压。负载低的时候降频省电，负载高的时候拉高频率冲性能，但一旦温度逼近上限或者功耗超过功耗墙，KMD就必须主动降频，防止硬件损坏。
你玩游戏的时候突然掉帧，GPU利用率显示满载但核心频率就是上不去，很可能就是KMD触发了温度墙或者功耗墙保护。这不是驱动“偷懒”，而是它在保护你的硬件。此外，笔记本合盖睡眠、唤醒后GPU状态的恢复，也完全由KMD负责。如果KMD的休眠恢复流程有bug，就会出现唤醒后GPU无法使用、或者GPU频率被锁死在最低档的诡异现象。
Windows上那个著名的“显示器驱动已停止响应并已恢复”弹窗，本质上就是KMD的TDR（Timeout Detection and Recovery，超时检测与恢复）机制在工作：GPU执行某个命令时超时，操作系统等不及了，判定KMD可能挂死，于是强制重置GPU驱动状态。看到这个弹窗，说明你的KMD层刚刚经历了一次“操作系统帮它重启”的事件。
3.5 上下文管理与GPU虚拟化
GPU上一个进程的一组资源（地址空间、命令队列、分配到的显存）统称为一个上下文。KMD要管理这些上下文的生命周期，还要在多个上下文之间切换。
切换背后的逻辑跟操作系统的进程调度类似。一个GPU上可能同时驻留图形上下文（游戏）和计算上下文（AI推理），KMD的调度器决定哪个上下文占用计算单元、占用多久。现代GPU还支持硬件级别的优先级和时间片抢占，让一个长时间运行的计算任务不会把整个GPU饿死。
虚拟化是上下文管理的延伸。云上的GPU实例、MIG（多实例GPU）分区、SR-IOV、WSL2的GPU-PV，这些技术的底层都离不开KMD和Hypervisor之间的配合。KMD要把GPU硬件能力“切开”或“代理”给多个虚拟机使用，同时保证彼此隔离。这也是为什么当你租一台云GPU来跑大模型时，KMD的版本和配置直接决定你拿到的到底是一张完整GPU的几分之一性能。开源社区里那些GPU调度、显存池化、虚拟化中间件（比如HAMI、GPU Operator这类项目），说白了都是在KMD暴露的底层能力之上做更加面向业务的资源编排。
3.6 与内核其它子系统的接口
KMD不是孤立存在的，它跟内核里的很多子系统都打交道。GPU要做DMA数据传输，需要跟内核DMA框架对接；GPU页表和CPU页表协同，需要跟内存管理子系统交互；GPU设备要纳入cgroup的隔离管理，需要跟资源控制框架协作。
还有一个容易被忽略的点：崩溃现场记录。KMD挂了的时候，系统能不能留下足够的调试信息，决定工程师能不能从崩溃转储里找到根因。很多时候你看到一条内核日志说GPU hang了，后面跟一长串寄存器dump，那就是KMD在关键时刻留下的“遗言”。学会读这些遗言，是GPU驱动调试的必修课。
4. 那些五花八门的故障，很多是KMD在“表态”
KMD是一个不怎么冒泡的角色——平时你看不见它，但它一旦出问题，症状往往非常显眼且五花八门。下面这张表是我这些年收集到的“症状与KMD责任”对应关系，看完你会发现，很多看起来毫无关联的故障，根子其实是同一层。
| 你看到的症状 | 背后KMD可能的责任 |
|---|---|
WSL里 nvidia-smi 报 gpu access blocked by the operating system |
虚拟化GPU层没有完成授权，KMD没有把设备正确暴露给guest |
| Windows弹“显示器驱动已停止响应并已恢复” | GPU执行超时，KMD触发TDR重置流程 |
| 游戏突然掉帧，GPU频率上不去 | 温度墙或功耗墙触发DVFS降频，KMD在保护硬件 |
| 多卡训练中途某张卡掉线 | 多卡通信超时，KMD对该卡的上下文进行了重置 |
| 开机黑屏或花屏，内核日志提示DRM初始化失败 | KMD在设备初始化阶段出错，或者固件加载失败 |
显存看着还够，但 cudaMalloc 分配失败 |
显存碎片化，或某个不可回收页把空间占住了 |
| 笔记本唤醒后GPU无法使用 | KMD的suspend/resume流程有bug，设备状态恢复失败 |
下面挑三个最常见的案例展开。
第一个是WSL2里的NVML报错。这个报错字面意思就是操作系统阻止了你的GPU访问。排查思路其实不复杂：先看宿主机的GPU驱动能不能正常工作，在Windows里跑一下 nvidia-smi；再看WSL里安装的CUDA工具包版本跟宿主驱动是否匹配；最后看WSL相关组件是否需要更新。很多情况下，宿主机驱动升级到新版本之后，WSL内的GPU虚拟化组件也需要同步更新，否则KMD和虚拟化层之间的协议就对不上。
第二个是Windows的TDR弹窗。这个弹窗背后的流程是：GPU执行某个命令超过了一定时间（默认一般是2秒）没有完成，KMD主动向操作系统报告“我卡住了”，操作系统让KMD尝试重置GPU状态。重置失败的话，通常就只能重启。有意思的是，这个问题在很多“改过GPU频率”的机器上特别常见——因为你把频率拉太高，GPU算力不稳定，执行时间长到超过TDR阈值，KMD只好判定超时。
第三个是训练中途掉卡。多卡训练时，每张卡上的KMD都在独立工作，卡与卡之间通过NVLink或PCIe通信。一旦某张卡的KMD因为超时或者错误触发了本地重置，负责梯度聚合的集合通信库（比如NCCL）就会探测到该卡失联，整个训练任务要么卡死要么直接崩掉。这时候排查的重点往往不是你的PyTorch代码，而是看看那张掉线的卡在内核日志里留下了什么“遗言”。
之所以说“这些故障是KMD在表态”，是因为KMD像一个守门员：它不会主动惹事，但所有硬件状态、资源协调、异常恢复的反馈都要经过它。当你具备“把五花八门的症状归结到KMD这一层”的思维习惯，你的底层排障能力就已经超过了大多数只写上层代码的工程师。
5. 零基础学KMD：避开我踩过的坑再上路
搞清楚了KMD是什么、管什么，接下来最关键的问题是：零基础怎么学？
5.1 别把几千页的芯片手册当教材
我见过太多想学驱动开发的人，上来就买一本GPU架构白皮书或者找一份硬件参考手册，打算从头读到尾。这条路我走过，基本是一条死胡同。原因很简单：硬件手册是“字典”，不是“教材”。它告诉你每个寄存器每一位是干什么的，但它不会告诉你为什么要设置这一位、什么时候需要设置、前置条件是什么。
正确姿势是自上而下学：先建立“驱动要解决什么问题”的框架思维，再去看具体硬件细节。就像学开车，先懂交通规则和驾驶逻辑，再去研究发动机每个部件怎么运作。等你真到了需要修发动机的阶段，翻开手册查就行了。
5.2 先补那些看起来有点远的内核基础
KMD本质上是Linux内核的一个模块。你至少要具备这些基础，才能顺畅地读KMD源码：
- 内核模块的加载/卸载机制，
module_init、probe这些入口函数 - 设备模型相关概念：bus、device、driver 三者之间的关系
ioctl和mmap这两个系统调用在驱动层的实现方式- 内核态的内存分配、并发同步手段（锁、完成量、工作队列）
- 中断处理的基本写法
推荐的学习材料是《Linux Device Drivers》（即LDD）和内核官方文档里的 Documentation/driver-api/drm.rst。LDD虽然年代久远，但里面关于字符设备、ioctl、内存管理、中断的讲解非常扎实，是理解KMD的底色。
5.3 动手第一课：写一个能做ioctl的内核模块
学KMD最忌讳只看不练。我的建议是，第一步先做一个小实验：写一个内核模块，注册一个misc设备，实现open和ioctl，然后在用户态写一个测试程序，通过 ioctl 传入一个字符串，内核模块把字符串打印到日志里。
这个实验看起来简单，但它打通了最关键的通路：用户态程序 <-> 系统调用 <-> 内核驱动模块。一旦你亲手让用户态的数据成功穿入内核态，你再看KMD里那些 ioctl 接口，就完全不是陌生面孔了。
实验环境用QEMU虚拟机或者WSL2里的Linux都可以。不推荐在主力开发机上直接加载自己写的内核模块——一个指针错误就可以让你当场黑屏。
5.4 用virtio-gpu当练习场，别急着上真卡
很多初学者一上来就想在自己有NVIDIA/AMD卡的机器上调驱动。我建议换个思路：用virtio-gpu作为第一个研究对象。
virtio-gpu是QEMU虚拟机里的虚拟GPU，对应的内核驱动在 drivers/gpu/drm/virtio 目录下，代码量小，逻辑相对干净，没有真实GPU那些动不动几百页的寄存器配置。更重要的是，virtio-gpu的驱动代码覆盖了DRM驱动的完整骨架：设备初始化、显示配置、GEM对象管理、命令提交队列。你可以在完整代码里看到KMD类驱动的框架长什么样，而且不需要担心把显卡调坏。
在virtio-gpu上跑通一个DRM驱动的基础流程之后，你会自然理解几个KMD绕不开的概念：DRM、KMS（内核模式设置）、GEM（图形执行管理器）。这三个概念是所有现代GPU内核驱动的骨架。
5.5 从virtio-gpu过渡到amdgpu
有了virtio-gpu打底，再去看 amdgpu 这种生产级驱动的源码，就不会一脸懵了。
建议按五条主线阅读：模块加载、设备初始化、内存管理、命令提交、中断处理。每条线抓住两三个关键入口函数，先搞清楚调用关系，再深入细节。
- 模块加载：
amdgpu的module_init入口在哪里，pci_driver的probe函数做了什么 - 设备初始化：
amdgpu_device_init里如何探测硬件IP、初始化固件 - 内存管理：
amdgpu_gem_create这类接口如何分配显存、建立页表 - 命令提交：
amdgpu_ring、amdgpu_ib这些结构体如何组织GPU命令 - 中断处理：
amdgpu_irq_handler如何分发不同类型的中断
你甚至可以编译一个带 CONFIG_DRM_AMDGPU=y 的内核，用 amdgpu.debug=1 这样的启动参数跑起来看日志。能亲眼看到驱动初始化时打印的那一大串GPU信息，比看十篇教程都管用。
5.6 常见误区速查
| 误区 | 真相 |
|---|---|
| 驱动开发就是调寄存器 | 内核并发、内存管理、调度设计才是真正的难点 |
| 没有NVIDIA卡学不了KMD | amdgpu、i915、virtio-gpu都是优秀的学习素材 |
| KMD是厂商给的闭源黑盒 | Linux下有大量开源驱动可读、可改、可调试 |
| 得先把硬件手册背下来再动手 | 框架理解优先，寄存器按需查阅 |
| 必须用Windows WDDM入门 | Linux DRM子系统的资料更多，调试工具更成熟，上手门槛更低 |
6. 学KMD到底图什么？这个技能的价值在哪
聊完技术细节，最后说说现实问题：投入这么多精力学一个相对偏门的领域，图什么？
第一，AI算力爆发让这个岗位变得极其稀缺。今天是GPU，明天可能就是昇腾这类专用AI加速芯片。这些芯片再强，也需要一套完整的驱动栈才能被上层框架用起来。驱动栈里最核心、最难替代的就是KMD这一层。很多AI加速芯片公司常年挂着驱动工程师的招聘，薪资相当可观，但能找到的人少之又少。
第二，几乎所有AI Infra层面的性能问题，最终都会追到驱动层。GPU利用率上不去、显存碎片化、多卡通信卡顿、推理延迟抖动——这些问题你在用户态怎么调都有天花板，但一旦你懂KMD，就能从分配策略、调度机制、中断路径这些底层维度去找根因。这种“从一次 cudaMalloc 失败一路追到内核页表”的能力，在AI Infra团队里是降维打击级别的存在。
第三，从职业成长的角度看，KMD是一个绝佳的“能力放大器”。它要求你同时掌握操作系统内核、并发编程、内存管理、硬件架构、性能分析。这些知识在任何底层系统方向都通用。你学完KMD之后再去看存储驱动、网络驱动、虚拟化组件，会觉得那些东西上手速度快得多，因为底层逻辑是相通的。
如果你决定入坑，第一周可以这样安排：
- 第1-2天：装一个Ubuntu虚拟机，体验一次完整的内核编译（不改代码，只编译安装）
- 第3天：写一个hello world内核模块，打通
insmod和rmmod - 第4天：写一个misc设备加ioctl，让用户态程序能向内核传数据
- 第5天：阅读virtio-gpu驱动的
probe函数，画出设备初始化流程 - 第6天：用同样的方法读
amdgpu的module_init和probe，对比两者差异 - 第7天：把自己理解的“GPU命令提交链路”写成文档，然后对着文档讲给一个不懂驱动的人听
这套安排看起来简单，但它能把抽象的KMD概念落地成你亲手写过、读过、调试过的代码经验。你不需要在这一周成为一个驱动专家，但你会建立起“KMD到底是什么”的具象认知。
回顾整个学习过程，我个人走过最大的弯路就是最开始太急于求成，翻开GPU编程指南就想把所有硬件细节吃透，结果一个多月过去，除了记住一堆寄存器名字，什么都没有真正掌握。后来我换了个思路——不再追着“硬件怎么做”跑，而是先问“驱动要解决什么问题”，从资源管理和并发协调这两条核心主线去读代码，原本一团浆糊的源码突然就有了脉络。如果你正打算入坑，希望这篇文章能让你从一开始就站在这条更省力的路上。
下一篇我会沿着DRM框架继续往下走，聊聊KMD在Linux内核里是如何被组织起来的，以及一个最小的KMD驱动长什么样。