Operating system 中断处理期间禁用中断

当内核当前正在处理中断时，为什么会禁用中断

如果丢失了包含重要消息的中断怎么办？

这可以防止可能溢出内核堆栈的“堆叠中断”。它还可以防止死锁和/或“钉住”

大多数硬件不会“丢失”中断。在中断期间，CPU的“中断标志”被清除，但中断控制器[一个单独的beast]仍然可用/启用，以记录新的中断。如果CPU正在处理硬件_A的中断（在“中断服务例程”ISR_A中），则仍然可以断言硬件_B的中断。它会被[中断控制器]记住，只是不会在那个时候中断CPU。当ISR_A返回时，中断标志将在退出时重新启用，现在，ISR_B将立即进入（其调用堆栈帧将在ISR_A的相同内存位置开始）

虽然中断不会丢失/丢弃，但ISR应该短[快速执行]，以最大限度地减少延迟。换句话说，ISR_A不应花费太长时间，以至于硬件_B将溢出一些内部状态/缓冲区[因为它在等待ISR服务时继续累积数据]

最小化延迟是仔细的内核设计和ISR设计的一部分。在Linux中，ISR可以分为ISR部分和“下半部分”或“tasklet”部分。ISR[在中断被禁用的情况下]执行设备维修/停止所需的最低限度操作（例如，清除设备中的一个位，以防止其立即重新发出中断）

---

然后，它启用相应的tasklet[在启用中断的情况下运行]来执行可能需要更长时间的更费力的操作。尽管名称不同，Tasklet与“ps”中显示的完整任务/流程不同。它们是一种[非常]轻量级/高效的方法，可以分解ISR必须完成的工作，以最大限度地减少延迟。

让我们回答每个问题

内核当前正在处理中断时，为什么会禁用中断？

尽管有许多类型的中断，如I/O、定时器、看门狗、串行端口、外围设备和DMA，但让我们以I/O为例。我们将讨论一个原始案例，并将其扩展到内核中

想象一个火灾报警/传感器位0/1连接到CPU的特定中断引脚。0为正常状态，1为火灾状态！然后将输入的中断配置为“电平触发”。传感器触发1的那一刻，ISR必须执行相关代码以警报或自动拨打消防部门。通常应在您进入ISR时清除中断。如果不清除，硬件会不断中断CPU，ISR内的安全代码将永远不会执行

CPU还需要维护其当前执行状态的堆栈。反复出现的中断使情况变得复杂

第二个例子是“边缘触发”或“过渡触发”，想象一系列位出现在输入线/引脚上（NRZ编码）。如果ISR的任务是将这些位组装成字（8、16、32，无论长度如何），我们需要清除中断，将位组装到缓冲区，并以周期的形式再次启用中断。不清除中断会导致glitch-y转换将1位误认为2位

因此，实践是设置并启用中断，如果中断，则清除中断，执行ISR代码，并在相关位置启用中断

内核

内核本身是一段关键的代码，调度程序（也是操作系统计时器、操作系统时钟）依赖于硬件计时器中断。CPU中包含中断逻辑的硬件部分保持状态转换。它还具有用于启用、禁用、屏蔽和设置中断优先级的硬接线逻辑

如果内核模块或潜水员模块应该安全地执行代码，那么只有在执行处理程序之前禁用中断才能获得确定性行为

如果丢失了包含重要信息的中断怎么办？

---

中断处理不应该太长（在启用中断之前）。人们应该根据中断的频率和处理程序的复杂程度正确地设计代码。

有些内核在中断处理程序中不禁用中断，并且具有中断堆栈，允许低优先级中断被高优先级中断中断。