操作系统设备管理探究：从设备分类到中断与DMA的I/O原理

操作系统四大资源管理——CPU、内存、文件、设备——前三个都有相对统一的抽象模型唯独设备管理这一块每次学都感觉像在跟一堆“脾气各异”的硬件打交道。这也是为什么我把I/O设备原理单独放在OS笔记的第38篇。设备管理的核心是搞清楚CPU怎么和键盘、磁盘、网卡、显示器这些外设协作以及操作系统怎么给上层提供一套统一、高效、可扩展的访问接口。这篇笔记我会从设备的分类逻辑、控制器与编址方式、I/O控制方式的演进、中断处理的完整链路、I/O软件层次这几个角度展开尽量把原理讲透也会穿插一些我实际调试驱动、读内核代码时的体会。适合正在复习操作系统的学生、准备面试的开发者以及刚接触内核驱动、想搞明白底层机制的读者。1. 设备管理为什么值得单开一章CPU和慢速外设之间的那点“错配”1.1 重新认识外设设备管理到底在管什么CPU的时钟周期是以纳秒计的一个现代处理器执行一条普通指令只需要零点几纳秒。而键盘、磁盘、网卡这些外设呢机械硬盘寻道一次是毫秒级别网卡收包虽然快但也要经过物理链路的高延迟和协议栈的层层处理。说白了CPU和外设之间的速度差距可以达到几个数量级。如果让CPU直接等外设那大部分时间都在空转。操作系统介入后要解决的事情就变成了怎么让CPU在等待I/O时不浪费算力怎么让不同设备以相对统一的方式被上层使用怎么保证多个进程同时访问同一个设备时不出乱子设备管理就是这样诞生的。它不是单纯地“控制硬件”而是一整套让CPU、内存、控制器、外设之间高效协作的机制。这里头涉及几个关键角色设备控制器负责具体设备的协议转换和数据缓冲、DMA控制器负责把数据从设备搬到内存或反向搬运、中断控制器负责把设备的“请求信号”转给CPU还有操作系统里的设备驱动、设备无关层、I/O调度器等软件组件。1.2 管理层要解决的四大矛盾把设备管理的需求“翻译”成要实现的功能可以浓缩成四个核心矛盾速度匹配CPU太快、设备太慢必须通过缓冲、缓存、DMA、异步通知等方式让双方不至于互相拖死。接口统一设备种类千差万别用户程序不能针对每个设备写一套逻辑所以操作系统要提供统一系统调用比如read/write/open/close背后再通过驱动去适配具体硬件。并发访问多个进程可能同时读写同一设备比如多个进程同时操作一个串口设备管理必须保证互斥、公平和死锁避免。错误隔离硬件出错的形态五花八门驱动崩溃不能把整个系统拖垮。现代操作系统通过将驱动放入独立模块、引入错误恢复机制来隔离故障。这四个矛盾贯穿整个I/O子系统的设计。你会发现后面讲到的每种机制——中断、DMA、缓冲、设备独立性——本质上都是在跟这四个矛盾较劲。1.3 从宏观视角看I/O系统全貌我学习的时候习惯先建一张“全景图”把各个组件串起来CPU通过总线和内存相连也通过总线连接各个设备控制器。设备控制器一边连着CPU/内存接口另一边连着实际设备。中断控制器挂在CPU旁边负责收集各设备的中断请求DMA控制器则可以绕过CPU直接访问内存。数据流向大致是设备 - 控制器内部缓冲 - DMA搬运到内存 - CPU从内存取数据反向同理。用户程序并不直接碰设备而是通过系统调用陷入内核再由内核把请求层层下发到驱动和控制器。这张图建立起之后再去看具体的代码和寄存器就有坐标了。2. 设备分类的底层逻辑块设备、字符设备和网络设备不是按“手感”分的2.1 块设备以块为单位可以随机访问块设备的典型代表是硬盘、SSD、U盘。它们的共同特征是以“块”为最小传输单位而且支持随机访问——也就是可以直接跳到任意一块去读不需要像磁带那样顺序倒带。这里要留意一个容易混淆的概念磁盘扇区通常512字节或4KB和文件系统块通常4KB不是一回事。设备驱动通常按扇区处理文件系统则按块组织。块设备还有一个特点就是读写往往不经过用户程序的逐个字节控制而是由内核的通用块层、I/O调度程序统一排队处理所以它的性能优化空间很大。在Linux里块设备看起来是/dev/sda、/dev/nvme0n1这样的文件但它们跟普通文件的最大区别是对块设备的读写可以直接定位到某个扇区。用户程序正常读写块设备用的还是read/write但可以通过lseek随意偏移。2.2 字符设备字节流就是它的全部字符设备最典型的例子是键盘、串口、鼠标、终端。它们不按块组织也没有明确的随机访问能力数据是以字节流的方式顺序出现的。你写在串口上的内容会按顺序发出去读回来的内容也是按到达顺序排队。字符设备通常不支持lseek或者即使支持也没有实际意义因为抽象模型里根本没有“位置”概念。用户程序对字符设备发一个read拿到的是设备当前已经准备好的字节流而不是按编号读取的文件块。在具体设备节点上字符设备和块设备的区分通过文件类型体现ls -l 时字符设备第一个字符是c块设备是b。而在驱动代码里它们分别注册为字符设备驱动和块设备驱动注册后会在内核里挂上不同的file_operations实际处理函数。2.3 网络设备不在文件系统里“挂名”的特殊设备网络设备网卡是个特例。它既不是按块随机访问也不是简单的字节流而是面向报文的。一个数据包是一个相对独立的单位包含完整的协议头和数据载荷。Linux网络设备不像块设备、字符设备那样在/dev下生成设备节点而是通过socket接口来访问。使用网络设备的过程通常是socket()创建套接字bind/connect绑定send/recv收发数据。内核协议栈在中间干活最终由网卡驱动把数据包发到物理链路。因为网络设备不走文件系统路径它没法用open打开再read这也是它会被单独归为一类的原因。2.4 设备号与设备文件用户视角的“门牌号”设备文件在被打开时内核从inode中读出主设备号和次设备号。主设备号用来定位驱动到底是谁例如买了个新芯片内核给它的驱动分配一个主设备号次设备号用来区分同一个驱动管理下的多个实例或分区。mkfs、mount、磁盘分区这些操作本质上都是围绕设备号展开的。比如你看到的/dev/sda1它背后对应的是一对设备号8, 1。内核拿到这个设备号通过主设备号找到驱动通过次设备号找到具体设备/分区。系统里所有设备文件都在/dev目录下而这个目录在现代Linux里由devtmpfs动态管理所以找不到设备节点时的第一反应应该是检查设备有没有被内核识别、驱动有没有加载。3. 设备控制器和I/O编址CPU和设备之间的那张“接头图纸”3.1 控制器内部到底有什么一块网卡、一个磁盘接口、一个串口芯片物理上都是设备但CPU没法直接跟它们对接。中间必须有控制器做“翻译”。控制器内部一般包含几类寄存器数据寄存器存放从设备读入或待写出的数据通常是512字节或4KB的小缓冲。状态寄存器反映设备当前状态比如忙不忙、数据是否就绪、是否出错。控制寄存器CPU往这里写命令比如启动读、启动写、设置传输模式。除了寄存器控制器里还有设备专用的逻辑电路、微码或者内部状态机。它的存在不仅为了协议转换也为了把设备的低速行为跟CPU的高速访问隔离——CPU操作寄存器实际上是操作控制器控制器再去跟设备慢吞吞地握手。我举个例子假设你写一个串口驱动往控制寄存器写“启动发送”命令然后等待状态寄存器里的“发送完成”位置1。看起来只是两个寄存器操作但背后控制器要按串口协议一位一位地把数据发出去还要处理波特率、停止位、校验位这些细节。没有控制器CPU就得亲自干这些极琐碎且极慢的活。3.2 独立编址与内存映射I/O两种访问模式CPU怎么访问这些寄存器主流有两种方式第一种是独立编址Port I/O。x86架构专门划出一个独立的I/O地址空间比如0x0000到0xFFFF用专门的in/out指令访问。这个方式的好处是不占用内存地址空间但缺点是必须有专门的指令而且访问粒度有限制。第二种是内存映射I/OMMIO。把设备寄存器映射到物理内存地址空间里CPU直接对某段地址进行普通的load/store就能读写设备寄存器。ARM、RISC-V平台普遍走这个路线。好处是访问统一但缺点是需要小心处理缓存问题通常要把这些地址标记为device内存避免CPU缓存干扰。实际工程里两者可以混用。比如x86平台上传统串口的寄存器用Port I/O访问而NVMe SSD的控制寄存器走MMIO。判断方法很简单如果你在代码里看到readl/writel那大概率是MMIO如果看到inb/outb那就是Port I/O。3.3 为什么内核对设备寄存器看得比数据还重很多初学者不理解为什么驱动代码里大量时间都在操作寄存器而不是直接读数据。关键在于寄存器是设备对外暴露的“唯一控制面”。你要让设备干什么、设备准备好了没有、数据从哪个口拿全看寄存器。访问设备寄存器时顺手也牵出了内核驱动开发的一个经典准则设备寄存器映射要统一管理杜绝乱映射。现代驱动框架里申请MMIO区域、把物理地址映射到内核虚拟地址、对寄存器做读写都有标准API。这些API不只是形式主义它们能防止驱动之间的地址冲突还能配合设备树等机制做硬件描述。内核调试时我经常用/dev/mem直接看某段物理内存里寄存器值的变化排查设备是否按预期响应。这个手段非常土但非常好用。4. I/O控制方式的四代演化轮询、中断、DMA与通道处理机4.1 程序直接控制最早的忙等最原始的I/O方式是程序直接控制也叫轮询polling。思路就是CPU反复读状态寄存器直到设备准备好再读写数据。比如// 等待设备数据就绪 while (!(status_reg DATA_READY)) { // 空转 } data read_data_reg();这段代码的毛病一眼就能看出来CPU在循环里不停空转既不做计算也不响应其他任务。如果一次传输要等很久CPU等于被这个设备“锁死”了。更糟的是键盘这种设备什么时候来数据完全不可控CPU要一直盯着状态寄存器什么事都干不了。所以除非是极其简单的嵌入式裸机编程或者中断实在用不起的场景一般不会用纯轮询做主要I/O。但是轮询并不是被淘汰的技术网络设备的NAPI机制、某些高性能场景下的DMA轮询模式本质上仍然在用轮询——因为当设备极其频繁地完成I/O时主动轮询比频繁陷入中断的开销更低。这是我学这一课时比较颠覆认知的地方。4.2 中断驱动I/O把CPU从等待里解放出来轮询的痛点在于CPU必须主动等。中断机制刚好反过来设备准备好了主动给CPU发一个信号CPU放下手头的事去处理它。中断驱动I/O的过程大致是CPU发出I/O请求后不再等待而是继续执行其他进程设备完成I/O后通过中断线通知CPUCPU响应中断跳转到对应的中断处理程序从设备读取数据或写入数据然后恢复之前的现场。中断的好处是显然的——CPU不用一直忙等等待期间可以调度其他任务。但也存在一个问题每次传输一个字节/字符都会触发一次中断。比如串口以115200波特率传输每秒约11520字节意味着每秒会来一万多次中断。每次中断都要做现场保护、处理、恢复CPU的开销依然不小。中断驱动I/O虽然解放了“等待”但没完全解放“搬运”。4.3 DMA数据搬运工登场既然CPU做搬运太浪费那就找一个专门的“搬运工”——DMA控制器DMAC。DMA控制器可以在不经过CPU的情况下在设备和内存之间直接搬运数据。DMA的典型工作流程如下CPU设置DMA控制器的源地址设备或内存、目的地址、传输长度。CPU发送启动命令DMA控制器开始工作。DMA控制器轮流接管总线把数据从设备缓冲搬到内存或从内存搬到设备缓冲。全部传输完成后DMA控制器发出一个中断通知CPU“活干完了”。这样一来CPU要做的事情只剩下前期的配置和最后的中断响应。中间大量数据搬运完全不占CPU这是磁盘、网卡等高速设备能跑满带宽的关键。不过DMA也带来一个新问题缓存一致性。CPU有高速缓存如果CPU在缓存里改了一段数据而DMA直接从内存读取拿到的是旧数据反过来DMA写入内存的数据可能没被CPU缓存感知到。所以内核在发起DMA之前通常要做cache flush或者invalidate操作确保缓存和内存一致。写驱动时如果遇到数据莫名不对首先怀疑DMA和缓存的一致性这是我很真实的排错经验。4.4 通道与I/O处理器让I/O自己管理自己DMA只能做简单的固定搬运如果需要执行复杂的I/O控制流程——比如从盘上连续读多个不连续区域的数据或者控制一组设备执行一串命令——可以交给通道处理机也叫I/O通道。通道本质上是一台能执行简单I/O程序的处理器。CPU只要把通道程序放到内存里然后告诉通道“去执行”通道就会自己完成整批I/O完成后才中断CPU。这样CPU连DMA的前期配置都省了只需要编写I/O程序并交给通道。大型机、存储阵列、部分高端磁盘控制器的思路都类似。在嵌入式领域比如AUTOSAR OS这类面向汽车的控制系统里也有I/O硬件抽象层的设计上层应用不会直接操作寄存器而是经过I/O驱动抽象层访问外设。对应关系其实和操作系统的I/O子系统很像只是更加讲究确定性、周期性和时间约束。如果你做嵌入式底层把这套原理迁移过去会发现很多概念是相通的。5. 一次中断请求的完整旅程从设备“举手”到内核“善后”5.1 中断信号到中断向量硬件做了什么中断的起点是设备想引起CPU注意于是往中断请求线IRQ上拉一个信号。现代系统里中断线会先经过中断控制器比如x86的APIC、ARM的GIC由它仲裁优先级、记录状态再送给CPU。CPU收到中断后会做两件事保存当前正在执行指令的上下文也就是把关键的寄存器状态保护好然后根据中断向量号找到中断服务程序入口。这个中断向量号对应一张表叫中断向量表或异常向量表里面存的是各类中断处理程序地址。中断向量号的来源很有意思有些是固定的比如缺页异常、时钟中断有些是设备注册驱动时动态申请的。驱动通过request_irq之类的接口把自己的处理函数挂到某个IRQ号上之后每当对应设备产生中断内核就能通过这个向量号找到驱动注册的处理函数。5.2 现场保护、处理与恢复内核的收尾流程中断处理程序是内核态代码运行在“中断上下文”里。它的标准流程包括保存现场压栈寄存器、调用具体处理函数、恢复现场、返回到被中断的进程继续执行。这里要特别强调“中断上下文”的含义。普通进程在用户态和内核态切换时是有进程概念支撑的——可以睡眠、可以被调度。但中断上下文不属于任何进程它是在一个被打断的执行流里插进来的“临时工”因此有很多限制不能调用可能睡眠的函数比如mutex_lock。内存分配要用GFP_ATOMIC不能乱阻塞。不能长时间占用CPU否则会拖累系统实时性。这些限制对写驱动的人来说是硬约束。我刚开始写驱动时曾经在中断处理函数里舒服地调用了printk觉得没什么问题直到高负载下系统变得极卡才开始意识到中断处理函数里的每个动作都要精打细算。5.3 上下半部机制为什么中断处理不能拖太久既然中断处理程序不能拖太久那如果数据量很大、逻辑很复杂怎么办经典的解法是把中断处理拆成两部分上半部top half和下半部bottom half。上半部就是我们刚说的中断处理程序它只做最紧急、必须快速响应的事比如读取设备寄存器里的数据、清除中断标志位、确认设备状态。至于数据处理、协议解析、唤醒等待进程这些相对耗时的工作放到下半部。下半部的实现方式有几种软中断softirq、tasklet、工作队列workqueue。软中断延迟小但约束多tasklet基于软中断但更简单工作队列则是把任务交给内核线程在进程上下文执行可以睡眠。选择哪种取决于任务的紧急程度和对睡眠的要求。上下半部机制还顺带解决了一个经典问题中断风暴。如果一个设备疯狂触发中断上半部每次只确认硬件状态把实际数据放到队列里交给下半部处理就能防止CPU被中断洪流淹没。Linux的NAPI在处理网卡高流量时也是类似思路网络中断先唤醒软中断收包如果流量大到一定程度就暂时关闭该设备的中断由轮询主动收包等队列清空再重新打开中断。6. I/O软件层次结构与设备独立性用户程序如何“无视”硬件差异6.1 四层模型用户层、设备无关层、驱动层、中断处理层I/O子系统在软件上分层每一层只跟相邻层打交道。经典的四层结构是用户层I/O库printf、read、write之类的库函数最终封装成系统调用。设备无关的操作系统软件处理系统调用、文件系统路径解析、设备号匹配、缓冲管理、错误报告等与具体硬件无关的逻辑。设备驱动程序面向具体控制器把上层请求翻译成控制器能懂的寄存器操作命令。中断处理程序响应设备中断完成状态确认、数据收取和后续下半部调度。为什么一定要分层核心目的就四个字设备独立。上层只需要跟“逻辑设备”打交道不关心底层到底是SSD还是机械盘、是USB键盘还是PS/2键盘。设备驱动只需面对上层的统一接口不用理解文件系统是怎么组织目录的。这样修改底层硬件时用户程序和文件系统代码都不需要动。6.2 从read()到磁盘扇区一条系统调用的完整旅程为了把分层讲透彻我跟一遍Linux系统里read请求的完整路径你会发现每一层都干了自己该干的活进程调用read(fd, buf, 512)触发系统调用陷入内核。虚拟文件系统VFS按fd找到对应文件结构和inode。如果目标是磁盘文件进入文件系统层比如ext4通过inode定位到逻辑块号。内核首先查页缓存如果数据已在页缓存直接复制给用户完成。如果没命中分配内核缓冲页构造一个bio请求块I/O的基本单位。通用块层把bio请求交给I/O调度器调度器决定在队列里如何排队合并。块设备驱动接收请求把扇区号、数据方向、内存地址翻译成设备控制器的寄存器命令必要时配置DMA。DMA控制器搬运数据完成后发中断。中断处理程序确认完成唤醒等待这个I/O的进程数据从内核缓冲区复制到用户缓冲区。这条路径看起来长但每一步都目标明确用户程序只要系统调用文件系统管逻辑布局块层和调度器管队列驱动管硬件中断管通知。也是因为这样崩了哪一层都相对容易排查。6.3 缓冲、阻塞与异步I/O性能调优绕不开的三件事I/O子系统里缓冲无处不在。硬件控制器有内部缓冲内核有页缓存、块缓冲用户空间也有应用自己管理的缓冲。缓冲的作用是削峰填谷设备来的数据忽快忽慢缓冲能暂存让CPU和数据消费方按自己的节奏处理。单缓冲、双缓冲、环形缓冲是比较基础的手段。比如键盘输入内核用一个环形缓冲区暂存按键事件即使应用处理稍慢按键也不会丢。串口驱动里的环形缓冲区更是常规操作。阻塞和非阻塞则关系着进程调度。阻塞I/O会让进程睡眠直到数据准备好再唤醒适合大多数场景。非阻塞I/O会让read立即返回没有数据就返回错误码适合需要同时处理多个事件的场景。再往上还有I/O多路复用select/poll/epoll和异步I/O本质上都是在控制“谁来等待、怎么通知”。理解底层的阻塞唤醒流程之后对这些高性能模式的理解会自然得多。在实际项目中我发现很多人遇到“程序读数据慢”第一反应是加缓存但操作系统层面早就有一整套缓冲策略了。真正值得先查的往往是驱动是否用了DMA、有没有启用页缓存、I/O请求有没有被糟糕地合并。盲目加用户态缓存很多时候只是心理安慰。7. 我自己学设备原理时踩过的坑7.1 中断上下文里千万别 sleep这是我从一次“假死”现场学到的。当时写一个简单驱动在中断处理函数里用了mutex_lock保护一个共享队列清理了中断标志之后还想从块设备读点配置数据。结果就是中断上下文试图获取一个已被占用的锁而锁的持有者又因为等待这个中断处理完成而无法继续直接死锁系统卡死只能强制重启。从此之后我的铁律是中断处理函数里只用spinlock和原子操作要sleep的事全部丢到工作队列。若需要分配内存用GFP_ATOMIC。这些细节教科书上都写了但自己踩一遍才真正长记性。7.2 不要迷信“/dev/sda永远代表同一块盘”另一个常见坑是把设备名当固定身份。系统起来后发现/dev/sda和/dev/sdb对调了或者插拔U盘后设备号变了直接导致脚本写错盘。现代系统里设备节点的命名由内核探测顺序决定并不稳定。要可靠标识一块盘应该用UUID、PARTUUID或者/dev/disk/by-id、by-path这类软链接。我在做数据恢复和镜像的时候每次都先ls -l /dev/disk/by-id确认到底是哪个盘这已经成了肌肉记忆。理解设备号机制之后就会明白为什么需要这么一层“动态映射”。7.3 读源码建议从一条I/O路径“一根筋”读下去如果你准备深入读内核I/O代码我最实在的建议是别一上来就摊开整个子系统。选一条最简单的路径比如一个字符设备驱动从一个read系统调用开始跟到驱动层最后再跟中断返回。把整条调用链在代码里走通比浏览十个文件的理解都深。我在第38篇笔记之前的十几个版本里一直读不懂设备模型后来就是靠“从read到uart驱动到中断处理”这一条线把字符设备框架、设备号、file_operations、中断注册这些概念串起来的。I/O原理最怕的就是停留在概念记忆一旦把这些概念挂在一条真实的执行路径上就都活了。这套设备管理的内容每次复习都会发现新的联系。比如看到文件系统的页缓存时会想到DMA与缓存一致性的坑看到网络协议栈时会想到NAPI和中断下半部的关系。操作系统本来就没什么孤立的章节I/O原理更是把前面所有的进程调度、内存管理、中断机制全串到了一起。多花点时间把这条路走通比死记硬背一堆名词有用得多。