Question

我是Linux Kernel的新手。我正在阅读“Linux内核开发，Robert Love第3版，第7章中断和中断处理程序”中的Linux内核。为了注册中断处理程序，Linux使用request_irq（）函数：

int request_irq(  
    unsigned int irq ,  
    irq_handler_t handler,  
    unsigned long flags ,
    const char *name,
    void *dev)

由于我是Linux Kernel的新手，所以我对Linux中的中断有些怀疑：

Q1 -> Are interrupt lines are software or hardware ?  
Q2 -> "irq" , first argument passed to request_irq() , is it interrupt line number or interrupt number ?
Q3 -> If interrupt line is hardware then , is it the criteria to limit the number of different interrupts an OS can support , if it is not then how we limit the number of different interrupts an OS can support ?

还有一个帮助，当我读书时，我对这些方面感到震惊：

“请注意，request_irq（）可以休眠，因此无法从中断上下文或其他代码无法阻塞的情况中调用。在睡眠不安全时调用request_irq（）是常见的错误。这部分是因为为什么request_irq（）可以阻止：确实很清楚。（页码：117）“

我无法理解这些行的含义，为什么request_irq（）不安全以及如何？我也无法理解中断上下文的含义是什么？

对于任何形式的帮助，我将感激你！
谢谢！

Answer 1

Q1：Linux - 就像几乎所有其他操作系统一样 - 从中断硬件（生成它们的硬件）中提取中断源（例如，您附加处理程序的内容）。

中断由称为中断控制器的专用硬件单元管理，中断控制器将中断源复用到CPU的一条（或可能是几条）中断线。

为什么需要这样的抽象有几个原因：中断控制器通常是分层的。在ARM SoC上尤其如此，其中CPU内核有两条直接中断线，其余的中断控制器挂断一个或多个中断控制器，提供数百个。作为系统设计人员，可以将现有线路上的其他中断控制器挂起，并让内核以统一的方式管理它们。

另一个原因是将设备驱动程序与特定系统的中断体系结构隔离开来。

某些中断可以是软件生成的。再次。操作系统将这个细节抽象出来。操作系统通常使用软件中断来执行优先于计划任务但不能在中断上下文中运行的处理。

Q2：Q1的答案应该回答这个问题。

问题3：（硬件）中断源数量的限制取决于系统中断控制器硬件的功能。用于管理它的内核数据结构是--AFAICR - 在编译时调整大小。

最后，中断上下文指的是用于执行中断服务程序的堆栈和CPU状态（例如寄存器）。由于中断可以在其他进程（或实际上是其他ISR）的任何时间发生，因此必须以有序的方式进行管理。

Answer 2

除了@markos回答之外，你还有一个关于request_irq()不安全的问题：它本身并不安全，如果你这样做，你就错了。但由于IRQ是有限的资源，请求可以阻止你的程序，因为它必须等到一个可供它使用。

现在，在正常的程序流程中，这不是一个太大的问题。程序无法阻止任何操作，但一旦注册了中断处理程序，它就可以正常继续但是，在处理中断的程序代码中，永远不允许程序阻塞。因为中断处理程序是在内核模式下执行的，并且不能被调度程序中断，所以现在程序可以在中断处理程序阻塞时运行。因此，不能释放任何资源 - 并且块永远不会结束。这会导致系统冻结。通常，您现在可以向其发送信号，以杀死它。信号作为中断处理。但是，由于已经处理了中断，并且您无法中断中断，因此无法正常工作。故事摘录：请勿阻止中断处理程序内的调用。

如何限制操作系统中的中断次数？

2 个答案: