中断处理程序中的上下文切换
为什么在执行中断处理程序时无法进行上下文切换？更具体地说，在linux内核中，中断处理程序在被中断的进程的上下文中运行。为什么不能在中断处理程序中进行上下文切换来调度另一个进程？
问题答案：
在多处理器上，上下文切换当然可以在执行中断处理程序时发生。实际上，将很难预防。
根据定义，在单CPU机器上，它一次只能运行一个控制线程。它只有一个寄存器集，一个ALU，等等。因此，如果中断处理程序正在运行，则根本没有资源可用于执行上下文切换。
现在，如果您是说，中断处理程序可以实际调用上下文切换代码并使之 实现
吗，好吧，我想在可以使之工作的某些系统上。但是对于大多数人来说，这没有什么价值，并且很难安排。CPU以更高的优先级运行，并且不能降低此优先级或中断级别之间的同步丢失。OS中的关键部分已经在与中断执行同步，这会带来复杂性。此外，上下文切换是通过更改堆栈来进行的，就像在线程用户模式程序中一样，因此很难想象当需要中断堆栈来从中断返回时如何发生。
-
我写了一个简单的字符驱动程序，并要求在gpio引脚上的IRQ，并为它编写了一个处理程序。 err=request_irq（irq，irq_handler，IRQF_SHARED|IRQF_TRIGGER_RISING，INTERRUPT_DEVICE_NAME，raspi_gpio_devp）； 静态irqreturn_tirq_handler（int irq， space*arg）； 现在从理论
-
在 linux 内核中你会发现很多关于中断和异常处理的话题 中断和中断处理 Part 1. - 描述中断处理主题 深入 Linux 内核中的中断 - 这部分开始描述和初步步骤相关的中断和异常处理。 初步中断处理 - 描述初步中断处理。 中断处理 - fourth part describes first non-early interrupt handlers. 异常处理的实现 - 一些异常处理的
-
终结篇 本文是 Linux 内核中断和中断处理的第十节。在上一节，我们了解了延后中断及其相关概念，如 softirq，tasklet，workqueue。本节我们继续深入这个主题，现在是见识真正的硬件驱动的时候了。 以 StringARM** SA-100/21285 评估板串行驱动为例，我们来观察驱动程序如何请求一个 IRQ 线，一个中断被触发时会发生什么之类的。驱动程序代码位于 drivers
-
延后中断(软中断，Tasklets 和工作队列)介绍 这是 Linux 内核中断和中断处理的第九节，在上一节我们分析了源文件 arch/x86/kernel/irqinit.c 中的 init_IRQ 实现。接下来的这一节我们将继续深入学习外部硬件中断的初始化。 中断处理会有一些特点，其中最主要的两个是： 中断处理必须快速执行完毕 有时中断处理必须做很多冗长的事情 就像你所想到的，我们几乎不可能同
-
进入中断处理流程 接下来，我们将要手动触发一个 Trap（ebreak），并且进入中断处理流程。 开启中断 为了让硬件能够找到我们编写的 __interrupt 入口，在操作系统初始化时，需要将其写入 stvec 寄存器中： os/src/interrupt/handler.rs use super::context::Context; use riscv::register::stvec; g