How to limits number of interrupts in a OS?

0
votes

I am new to Linux Kernel. I was reading about the Linux Kernel from "Linux Kernel Development , Robert Love 3rd Edition, chapter 7 Interrupts and Interrupts Handler". For registering a interrupt handler , Linux uses request_irq() function as : 

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

Since i am a new guy for Linux Kernel , so i have some doubts regarding interrupts in 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 ?

One more help , when i was reading , i got struck at these lines :

"Note that request_irq() can sleep and therefore can not be called from interrupt context or other situations where code can not block . It is common mistake to call request_irq() when it is unsafe to sleep.This partly because of why request_irq() can block : It is indeed clear. (Page number : 117)"

I am unable to get the meaning of these lines , why request_irq() is not safe and how ? And i am also not able to understand what exactly the interrupt context means ?

For any kind of help , i will be grateful to you!
thank you!

2
linuxlinux-kernel
how would you currently answer those question? please try to answer them on your own, we cann tell you if it's correct or not. But show us some work you did on your own first, please. – Johannes H.
@JohannesH. , hey....thank u so much , really a good advise. I have studied OS course in my colg , and really i was unable to answer these questions on my own , thts y i asked ....but m really thankful for your advise. – Saurabh Jain

2 Answers

2
votes

Q1: Linux - like just about every other operating system - abstracts interrupt sources (e.g. what you attach a handler to) from interrupt hardware (the hardware that generates them).

Interrupts are managed by specialised hardware units called interrupt controllers, which multiplex interrupt sources into a one (or possibly a few) interrupt lines to the CPU.

There are several reasons why an abstraction such as this is required: interrupt controllers are often hierarchical. This is particularly the case on ARM SoCs where the CPU core has two direct interrupt lines with the remainder hanging off one or more interrupt controllers providing several hundred more. As a system designer it is possible to hang additional interrupt controllers off existing lines and get the kernel to manage them in a uniform way.

The other reason is to insulate device drivers from the interrupt architecture of a particular system.

Some interrupts can be software generated. Again. the operating system abstracts this detail away. Software interrupts were commonly used by operating systems to perform processing that has higher priority than scheduled tasks, but which cannot run in an interrupt context.

Q2: The answer to Q1 should answer this one.

Q3: The limit to the number of (hardware) interrupt sources is dictated by the capabilities of interrupt controller hardware in the system. The kernel's data structure used to manage this is - AFAICR - sized at compile time.

Finally, an interrupt context refers to the stack and CPU state (e.g. registers) used to execute an interrupt service routine. As interrupts can occur at any time whilst other processes (or indeed, other ISRs) this must be managed in an orderly fashion.

0
votes

In addition to @markos answer, your additiona question about request_irq() being unsafe:it's not unsafe per-se, if you got it that way, you got it wrong. But as IRQs are limited resources, requesting one can block your program, because it has to wait until one gets available for it to use.

Now, in normal program flow, this isn't too much of a problem. The program cannot do anything whil it is blocked, but it can continue normally once the interrupt handler is registered.
In program code that handles interrupts however, a program is never allowed to block. Because the interrupt handler is executed in kernel mode and cannot be interrupted by the scheduler, now oter program can run while the interrupt handler blocks. Therefore, no ressources can be freed - and the block will never end. This causes your system to freeze. Normally, you could now send signals to it, to kill it. Signals are processed as interrupts. But as an interrupt is already handled, and you cannot interrupt interrupts, this won't work. ENd of story: Don't us blocking calls inside interrupt handlers.