根据一些 Linux 书籍
kernel code that services system calls issued by user applications runs on behalf of the corresponding application process and is said to be executing in process context. Interrupt Handlers run in interrupt context.
现在svc和irq是两个异常(exception)。
因此，当 linux 处理 svc 时，它处于进程上下文中，而当它处理 irq 时，它处于中断上下文中。它是这样映射的吗？
只需对此进行一次编辑
书中还提到，tasklets/softirqs 在中断上下文中运行，而 workqueues 在进程上下文中运行。那么这是否意味着 tasklet 将以 CPSR.mode = IRQ 运行？
最佳答案
如果我以正确的方式理解你的困惑:
由于 Linux 是一个强大的、先发制人的、复杂的操作系统，与裸机硬件相比，它可以更好地处理概念，例如处理中断或服务软件陷阱。
例如，当主管调用 (svc) 发生硬件切换到 SVC 模式时，Linux 会像准备一些数据结构来进一步处理它一样简单地处理它，然后退出 SVC 模式，这样核心就可以继续在用户模式下服务，从而使它成为可能遇到更多异常模式而不是阻止它们。
对于 IRQ 模式也是一样，Linux 在 IRQ 模式下处理最少。它准备 IRQ 发生的数据结构，应该调用哪个处理程序等，然后立即退出 IRQ 模式以允许在该内核上发生更多事情。稍后一些其他内部内核线程可能会进一步处理该中断。由于硬件虽然相对简单但运行速度非常快，因此中断处理与许多进程并行运行。
这种高级方法的缺点是它不能保证响应时间要求，或者它的开销在 MCU 等较慢的硬件上变得可见。
因此 ARM 的异常模式为 Linux 提供了两件事:消息类型和由硬件支持支持的优先级。
- 消息类型是关于异常模式的，如果它是 SVC、IRQ、FIQ、DATA ABORT、UNDEFINED INSTRUCTION 等。所以当硬件进入异常模式时，Linux 隐式地知道它正在处理什么。
- 优先级是提供功能强大且响应迅速的硬件，例如，系统应该能够在处理一些不太重要的主管调用时确认中断。
- 硬件支持是为了更轻松、更快速地处理以上两个问题。例如，一些寄存器被存储，或者有一个额外的系统模式来更容易地处理重入 IRQ。
关于ARM 中的 Linux Process Context 和 SVC 调用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23406171/