驱动之路#23:Linux中断(面试必考题)
- 2026-06-29 01:56:58
欢迎关注，每周更新！☞
本合集分享的是，我当初学习Linux驱动的来时路——《《驱动之路》开篇：自序&前言》。
正文
在嵌入式Linux开发中，中断就像设备的“紧急呼叫器”——键盘按下、串口收数、ADC采集完成、定时器溢出，本质都是硬件在给CPU打“紧急电话”：“停下手头的活，先处理我这急事！”
很多开发者调试中断时，总会陷入困惑：“明明中断触发了，服务函数却没反应？”“中断处理完，系统直接卡成PPT？”其实不是代码写得差，而是没摸清Linux中断的“处理规矩”——它不是“一喊就办”的直肠子，而是一套环环相扣的标准化流程，从“打电话”（触发）到“挂电话”（恢复），每一步都有明确分工。
1 中断的“本质”
用一句大白话总结：中断，就是硬件主动给CPU发“紧急求助信号”，强行打断CPU当前的工作，让它优先处理紧急事务，等事办完，再回头接着干之前的活。
做个生活化类比，瞬间理解：
CPU = 正在专心写代码的程序员；
中断 = 突然响起的紧急电话（客户催单、领导查进度）；
流程对应： 程序员专心写代码（CPU执行主程序）--> 电话铃响（中断触发）--> 程序员停下手中活，记住自己写到哪一行（保存现场）--> 接电话，快速处理紧急事（执行中断处理）--> 挂电话，回到之前的位置，继续写代码（恢复现场、继续执行）。
2 中断两个核心
Linux中断处理不是CPU“单打独斗”，需要两个核心角色配合，就像“接线员+调度员”：
IRQ控制器（如GIC，通用中断控制器）：硬件层面的“接线员”，专门接收所有硬件的“紧急电话”，筛选优先级，再转给CPU，避免混乱；
内核中断子系统：系统层面的“调度员”，负责管理所有中断，找到对应的“处理人员”（中断服务函数），安排处理顺序，确保高效推进。
3 Linux中断处理流程
Linux中断处理的核心逻辑很简单：先快速响应，再慢慢处理，最后恢复原样。以下基于最常用的ARM架构（如RK3576开发板），一步步拆解完整流程。
[1.中断触发]-->硬件喊“救命”（如按键按下）;
[2.IRQ控制器响应] --> 接线员分诊：判断紧急程度（判断中断优先级）；
[3.CPU响应中断] --> 程序员停活，记位置（保存现场——保存在内存，称为栈。）；
[4.内核中断调度] --> 调度员找处理人员（根据中断号找到对应的中断服务函数）；
[5.执行中断处理（上下半部）] --> 事办完了；
[6.恢复现场] --> 程序员回头继续干活；
[7.退出中断，等下一个电话]。
步骤1：中断触发——硬件“打通紧急电话”
这是整个处理流程的起点，也是最基础的一步。当硬件发生特定事件时，会主动向IRQ控制器发送“紧急电信号”，相当于打通了“紧急电话”，告诉系统“我有急事，快处理”。
常见触发场景：GPIO引脚检测到高电平（按键按下）、UART接收完1字节数据、ADC采集完一次电压、定时器溢出，这些硬件都会主动“打电话”求助。
步骤2：IRQ控制器响应——接线员“分诊排序”
IRQ控制器这个“接线员”收到电话后，不会直接转给CPU，而是先做3件事，避免“乱套”，确保高优先级的事优先处理：
确认来电者：搞清楚是哪个硬件（比如GPIO1、UART2）打的电话，避免找错“处理人员”；
判断紧急程度：对比当前所有未处理的“电话”，优先转接高优先级中断（比如硬件故障中断，比串口接收这种“小事”更紧急）；
屏蔽低优先级电话：处理当前电话时，暂时不接同等级或更低等级的电话，避免被打断，确保当前紧急事能顺利处理。
做完这3件事，“接线员”才会把电话转给CPU，通知它“有紧急事，快接”。
步骤3：CPU响应中断——程序员“停活记位置”
CPU收到“接线员”的通知后，会立刻停下当前正在做的事（比如执行主程序、跑应用线程），然后做两件关键操作，避免“忘了自己之前干到哪”：
保存现场：把当前CPU寄存器里的内容（比如正在执行的代码位置、临时数据）保存到“备忘录”（栈）里，确保后续能准确回到当前位置；
暂时关断部分电话（可选）：根据系统配置，暂时不接某些低优先级电话（避免被打扰），然后跳转到“处理人员办公室”（内核中断入口地址）。
步骤4：内核中断调度——调度员“找处理人员”
CPU跳到内核中断入口后，“调度员”（内核中断子系统）就开始工作了，核心任务是“快速找到能处理这个电话的人”，不浪费时间：
要“来电编号”：内核读取IRQ控制器的寄存器，获取中断号——每个硬件的中断都有唯一编号（比如GPIO1的中断号是60），相当于“来电者的身份证”；
查“通讯录”：通过中断号，在内核的“中断向量表”（相当于通讯录）里，找到对应的“处理人员”——也就是我们提前写好的中断服务函数（ISR）；
安排顺序：如果有多个“电话”在等，就按优先级排序，让“处理人员”一个个处理，不插队、不混乱。
步骤5：执行中断处理——核心中的核心，分“快慢活”
这是最关键的一步，也是很多开发者踩坑的地方。Linux很聪明，它把中断处理分成了“快慢两部分”（上下半部机制），就像处理紧急电话：先快速说清核心诉求，再慢慢细化处理，避免占用CPU太久，导致系统卡顿。
上半部（Top Half）：急活快办
相当于“接电话时快速说清诉求”，只处理最紧急、最核心的事，速度要快（通常几十微秒搞定），期间不允许被任何中断打断（相当于接电话时不允许被插话）。
核心工作：清除中断标志（告诉硬件“我收到你的请求了，别再一直打”）、保存关键数据（比如串口接收的1字节数据）；对应代码：我们写的中断服务函数（ISR），通过request_irq 函数注册给内核。
下半部（Bottom Half）：慢活细办
相当于“挂电话后整理诉求、解决问题”，处理耗时的后续工作，可被高优先级中断打断（比如处理后续工作时，更高优先级的电话打进来，就先暂停），不占用CPU的“紧急通道”。
核心工作：解析数据、上报数据给应用层、处理异常情况；
常用实现方式：workqueue（最常用，适合需要“暂停等待”的操作）、tasklet（适合快速处理、不暂停的活）。
举个串口接收的例子，一看就懂： - 上半部（急活）：1毫秒搞定——读取串口寄存器的1字节数据，保存到缓冲区，清除中断标志； - 下半部（慢活）：慢慢处理——解析缓冲区的所有数据，判断数据是否完整，再发送给应用层。
步骤6：恢复现场——程序员“回头继续干活”
上下半部的工作都做完后，“调度员”会从“备忘录”（栈）里，把步骤3保存的CPU寄存器内容恢复回来——相当于程序员看完“备忘录”，记起自己之前写到哪一行代码，回到原来的位置，继续执行主程序。
步骤7：退出中断——等待下一个“紧急电话”
恢复现场后，CPU退出“中断模式”，重新开启中断响应（如果步骤3中关闭了部分中断），就像程序员挂掉电话，继续专心写代码，等待下一个紧急电话打进来——整个中断处理流程，完美闭环。
4 手把手写中断处理代码
理解了流程，最关键的是“怎么写代码实现”。下面以GPIO中断为例，写一段Linux内核驱动代码，涵盖中断注册、上半部、下半部，新手也能直接复制使用，看完就能上手调试。
#include#include#include// 中断号（需根据设备树配置，比如RK3576的GPIO1中断号是60）#defineGPIO_IRQ_NUM 60// GPIO引脚（示例：GPIO1_0，计算方式：1*32 + 0）#defineGPIO_PIN 1*32 + 0// 下半部：用workqueue处理耗时操作（后续工作处理员）static struct work_struct gpio_work;// 上半部：中断服务函数（急活处理员，快速响应）staticirqreturn_tgpio_irq_handler(int irq, void *dev_id){// 1. 清除中断标志（必须做！不然硬件会一直发中断，相当于电话一直响）gpio_clear_int_edge(GPIO_PIN);// 2. 把耗时活交给下半部，让上半部专心干急活schedule_work(&gpio_work);return IRQ_HANDLED; // 告诉内核：这个中断我处理完了}// 下半部：workqueue处理函数（慢活细办）staticvoidgpio_work_handler(struct work_struct *work){// 处理耗时操作：读取GPIO电平、上报数据等printk("GPIO中断下半部：当前引脚电平 = %d\n", gpio_get_value(GPIO_PIN));}// 中断初始化（驱动加载时执行，给处理员分配任务）staticintgpio_irq_init(void){int ret;// 1. 初始化下半部（给慢活处理员安排工位）INIT_WORK(&gpio_work, gpio_work_handler);// 2. 注册中断（给中断挂号，指定处理员和触发方式）ret = request_irq(GPIO_IRQ_NUM,gpio_irq_handler,IRQF_TRIGGER_RISING, // 上升沿触发（按键按下时触发）"gpio-irq-demo", // 中断名称（调试时方便查找）NULL); // dev_id（中断共享时使用）if (ret < 0) {printk("中断注册失败！错误码：%d\n", ret);return ret;}printk("GPIO中断注册成功，等待触发～\n");return 0;}// 驱动卸载时释放中断（处理员下班，归还工位）staticvoidgpio_irq_exit(void){// 1. 取消未完成的慢活，避免处理员下班了还在干活cancel_work_sync(&gpio_work);// 2. 释放中断，注销挂号，归还系统资源free_irq(GPIO_IRQ_NUM, NULL);printk("GPIO中断释放成功，处理员下班啦～\n");}module_init(gpio_irq_init); // 驱动加载入口module_exit(gpio_irq_exit); // 驱动卸载入口MODULE_LICENSE("GPL"); // 内核驱动必加，遵循GPL协议
5 三个关键细节（避坑重点）
触发方式：常用3种——上升沿（按键按下）、下降沿（按键松开）、双边沿（按下/松开都触发），要和硬件实际情况匹配；
上半部禁忌：绝对不能“摸鱼”——不能调用msleep、kmalloc等可能“暂停”的函数，执行时间必须控制在几十微秒内，不然会阻塞其他中断；
下半部选择：需要“暂停等待”（比如访问内核资源）用workqueue；不需要暂停、快速处理用tasklet，按需选择即可。
6 三个常见问题
调试中断时，新手最容易遇到以下3个问题，结合前面的流程，给大家讲清原因和解决方法，不用再对着屏幕抓头发。
问题1：中断不触发
可能原因：设备树配置错（中断号、GPIO引脚和硬件对不上）、中断未开启（IRQ控制器没启用该中断）、硬件接线错（GPIO引脚没接对，信号传不过来）；
排查方法：核对设备树和硬件手册、用
cat /proc/interrupts查看中断是否注册成功、用万用表测GPIO电平，确认信号正常。
问题2：中断触发，但ISR不执行
可能原因：中断优先级太低（被高优先级中断阻塞）、中断被屏蔽（用local_irq_disable()关闭了中断）、注册参数错（触发方式和硬件不匹配）；
排查方法：用
cat /proc/interrupts看中断触发次数、调整中断优先级、核对触发方式和硬件一致。
问题3：中断处理导致系统卡顿
可能原因：上半部干了慢活（在ISR里写数据解析、循环等耗时操作）、下半部未正确实现（后续工作堆积）；
解决方案：把耗时操作全部移到下半部、优化上半部代码（控制在几十微秒内）、不调用会“暂停”的函数。
7 总结
1. 流程本质：硬件触发→IRQ分诊→CPU响应→内核调度→上下半部处理→恢复现场→退出中断，全程分工明确，高效有序；
2. 核心设计：上下半部机制是灵魂，目的是“快速响应紧急事，不耽误正常活”，平衡实时性和系统流畅度；
3. 调试技巧：遇到问题，先查/proc/interrupts看中断状态，再用dmesg看内核日志，聚焦“触发→注册→执行”三个环节。
（完）
