题目

下面关于中断和异常的说法中，错误的是（ ）。

错因

B

把"内核服务例程"理解成某种独立的程序模块，觉得简单的系统调用（如 getpid）"只是查个值就返回"，似乎不需要专门的例程——于是怀疑 B。但 OS 实现里，即便最简单的 syscall 也走完整入口流程：syscall 指令陷入 → 查 syscall 表 → 调用对应的 sys_xxx 函数 → 返回。每个系统调用号都明确对应一个内核服务函数，这是基础架构。

C

把"中断处理"误理解成包括响应阶段的全过程：响应最初一瞬（PSW 还没保存完）CPU 似乎还在用户态。但题面措辞是"处理程序开始执行"——指那段处理代码跑起来的那一刻，硬件已替我们完成状态切换，CPU 必然在内核态（否则它访问内核数据结构会触发保护异常）。

D

误以为现代 OS 用统一的"设备驱动框架"管理一切，"添加新设备"只是装个驱动包，OS 自动接管中断——觉得"注册中断服务例程"是过时的描述。但驱动框架内部本质就是通过接口（Linux 的 request_irq、Windows 的 IoConnectInterrupt）把 ISR 挂到中断向量上——这就是注册，只是开发者感知不到。新设备类型必须配套自己的 ISR，否则中断信号无人响应。

总解析

判定思路：题目反向措辞（错误的），逐项核验。关键考点是分清 "中断/异常发生时" 与 "中断处理程序执行时" 这两个时刻 CPU 所处的状态。

完整时序拆解：

时刻	描述	CPU 状态
①	用户进程运行	用户态
②	中断/异常发生	通常仍是用户态（多数 I/O 中断、时钟中断、syscall trap、缺页等都在用户进程运行时触发）
③	硬件响应：保存 PSW/PC、切换状态位、跳转到中断向量	切换中 → 内核态
④	中断处理程序开始执行	内核态（必然）
⑤	处理结束 IRET 恢复现场	切回原态（多为用户态）

A 描述的是 ②，把它说成"内核态"——这是错的，本题答案。C 描述的是 ④，已切到内核态，正确。注意：A 与 C 的区分点不在于是不是内核态，而是"事件发生那一刻" vs "处理程序跑起来那一刻"——前者是触发切换的原因，后者是切换完成的结果。

逐项核对：

选项	描述	对错	关键
A	中断/异常发生时 CPU 在内核态	✗	发生瞬间 CPU 通常在用户态，是触发切换的事件本身
B	每个系统调用都有对应内核服务例程	✓	基本架构：syscall 号 → syscall 表 → sys_xxx 函数
C	中断处理程序开始执行时 CPU 在内核态	✓	处理程序是内核代码，必须在内核态运行
D	添加新设备类型需注册 ISR	✓	驱动核心组件，否则中断信号无人响应

速记：发生瞬间 ≠ 处理执行——前者多数在用户态（事件让 CPU 被迫切换），后者必然在内核态（特权代码必须有特权状态）。

最终答案是 A。