4-5 Linux 中断进程 --- kill （kill -2 实验）

1、信号：传递给 Liunx 的事件发生通知机制。

2、kill -l：显示所有信号。一共有62个信号（没有32、33）。

3、常用的信号有：

kill -2 PID —— 正常中断进程（Ctrl + C 一样）。程序在结束之前,能够保存相关数据,然后再退出。

kill -9 PID —— 强制杀死一个进程。

kill -15 PID —— 正常方式终止一个程序。中断进程时应首先用 -15，以便于其能够预先清理临时文件和释放资源。-9 作为最后手段，应对那些失控的进程。

--------------------------------------------------------------------------------

1）、kill -2 中断后台运行的进程。

红色下划线：sleep 10000 &—— 后台运行延时 10000 秒的命令，进程 ID 为1516。

ps -j —— 以作业格式列出进程信息，可以看到 1516 sleep 命令的进程。

（PID：进程 ID、PGID：线程组 ID、SID：会话 ID、TTY：进程运行的终端，标识那个终端控制。（pts远程终端、tty系统终端）、TIME：进程运行的时间 和 CMD：命令的名称和参数）。

jobs -l —— 列出后台运行的命令，此孝可以看到 1516 sleep 命令正在后台运行。

黄色下划线：kill -2 1516 —— 中断1516 进程。执行成功后，按 Enter 回车系统会给出提示Interrupt 提示（中断进程）。

蓝色方框：ps -j 已查询不到 1516 sleep 的进程。jobs -l 也没有后台运行的命令。

2）、kill -2 配合 fg 查看中断挂起的进程。

红色下划线：前台执行 sleep 10000 （延时10000秒）后 ctrl + z 挂起。

黄色下划线：ps -j 查看进程，可以看到 1344 sleep 进程。jobs -l 查看后台进程 1344 的状态是stopped 暂停状态。

蓝色下划线：kill -2 1344 中断 1344 进程。

绿色下划线：ps -j 查看进程，仍有 1344 sleep 进程。jobs -l 查看后台进程 1344 的状态是stopped 暂停状态。

暂时这样看，好像 kill -2 并没有起到中断进程的作用。

然而，用 fg 把后台的命令调至前台运行时可以发现 1344 sleep 已经被中断。

红色下划线：fg 把已经执行了 kill -2， 状态为 stopped 的1344 sleep命令调至前台执行。系统也反馈已经调至凯橡前台执行。（此时，实际上已经执行了 kill -2 中断了进程）

黄色方框：ps -j 已经没有了 1344 sleep 的进程。

蓝色方框：jobs -l 后台也没有指令。

3）、kill -2 配合 bg 查看中断挂起的进程。

通过上面的思路，kill -2 配合 bg 实验看看效果。同样的首先挂起一个命令，状态为 stopped 暂停。然后用 bg 命令恢复执行。

前面的步骤都是一样，挂起一个命令。通过 ps 和 jobs 查看进程和后台确认有 1379 的进程，状态为 stopped 暂停。然后执行 kill-2 中断进程，再次通过ps 和 jobs 查看进程和后台命令。确认状态为 stopped  1379 的进程仍然存在。

此时，用 bg 恢复运行挂起的命令，系统提示 sleep 命令已恢复在后台运行。然而通过 ps -j 查看进程会发现 sleep 已经被中断。jobs -l 查看后台也没有了运行盯扒旁的 sleep 命令了。

从实验上看：

1、后台命令运行时（Running），执行 kill -2 可以中断进程。

2、挂起命令，处于暂停状态时（Stopped），执行 kill -2 后通过 ps 还可以查询到进程， jobs还可以查询到后台命令，状态仍然是 Stopped 暂停状态。实际上，用 fg 把暂停的后台进程调至前台运行时，系统反馈 sleep 命令调至前台运行。而再用 ps 查询不到进程，已经中断了进程。用 jobs 已经查询不到后台命令。

3、挂起命令，处于暂停状态时（Stopped），执行 kill -2 后通过 ps 还可以查询到进程， jobs还可以查询到后台命令，状态仍然是 Stopped 暂停状态。用 bg 把暂停的后台命令恢复运行时，系统反馈 sleep 命令在后台运行。再用 ps 查询进程已经中断，用 jobs 已经查询不到后台命令。

本文虚卜基于 RockPI 4A 单板Linux4.4内核介绍中断调用流程。

ARMv8包括两种运行状态：AArch64和AArch32。

AArch64中不再使用AArch32中的7种特权模式，而是提出了Exception Levels的概念，包括：

1）EL0：用于用户态程序，权限最低

2）EL1：给内核使用，权限稍高

3）EL2：虚拟化相关，权限更高

4）EL3：安全相关，权限最高

Linux内核中一般只使用EL0和EL1。

AArch64异常向量表裂誉带中的异常包括：

1）Synchronous exception（同步异常）

2）SError

3）IRQ

4）FIQ

注：SError、IRQ和FIQ属于异步异常。

在Linux内核中，在 arch/arm64/kernel/entry.S 文件中定义了异常向量表，内容如下：

选取 el1_irq() 函数介绍Linux内核中断的调用流程。

文件： arch/arm64/kernel/entry.S ，调用流程如下：

1、handle_irq()初始化

在 DTS 解析阶段完成 handle_irq() 函数的初始化，流程如下：

gic_irq_domain_map() 函数中完成了 handle_irq() 函数的赋值，具体执行如下：

2、handle_irq()实现

以共享外设中断 SPI 的中断处理函数 handle_fasteoi_irq() 为例，继续跟踪中断的执行过程。

handle_irq_event_percpu() 函数会调用已经注册的中断处理函数，同时唤醒 irq_thread 线程。

3、中断处理线程

在使用 request_threaded_irq() 函数申请中断时，会创建一个 irq_thread 线程，调用流程如下：

irq_thread 线程平时在睡眠状态，等待 handle_irq_event_percpu() 函数唤醒，进一步执行已注册的中断处理线程函数。

使用 DRM 框架中 HDMI 中断验证中断调用流程。

文件： drivers\gpu\drm\bridge\synopsys\dw-hdmi.c

在中断处理函数 dw_hdmi_hardirq() 和中断处理线程函数 dw_hdmi_irq 中增加 dump_stack() 调用（ 注：仅限于调试验证 ）。

插入 HDMI 线，系统启动后，显示中断调用流程的肆芦日志如下：

和

---