An in-depth analysis of Linux device driver interrupts (1)

1. Introduction

Linux interrupts are divided into two types: soft interrupts and hard interrupts. Let me state that the meaning of soft and hard here refers to software-related and hardware-related, rather than software-implemented interrupts or hardware-implemented interrupts.

Soft interrupt is the "signal mechanism". A soft neutral is not a software interrupt. Linux uses signals to generate various interrupt operations for the process. There are 31 signals that we know now. The specific content is skipped here. Interested readers can refer to the relevant references [1]. Generally speaking, soft interrupts are caused by trigger events of the kernel mechanism (such as process running timeout), but it cannot be ignored that a large number of soft interrupts are also caused by hardware-related interrupts. For example, when a printer port generates a hardware interrupt, It will notify the hardware-related hard interrupt, and the hard interrupt will generate a soft interrupt and send it to the operating system kernel, so that the kernel will wake up the processing process sleeping in the printer task queue based on this soft interrupt.

Hard interrupt is an "interrupt handler" in the usual sense. It directly handles the interrupt signal sent by the hardware. When the hard interrupt receives the interrupt signal it should handle, it goes back to the device it drove to look at the device's status register to understand what happened and perform corresponding operations. We will not discuss soft interrupts, which are things to consider in process scheduling. Since we are discussing device driver interrupts, the focus is on hard interrupts. What we are discussing here are hard interrupts, which are hardware-related interrupts.

2. Interrupts are generated

The reason for interrupts is that the peripheral device needs to notify the operating system that something has happened there, but the function of the interrupt is just a device alarm light. When the light is on, the interrupt handler only knows that something has happened. , but you have to go to the equipment in person to see what happened. In other words, when the interrupt handler learns that an interrupt has occurred on the device, it does not know what happened to the device. Only when it accesses some status registers on the device can it know what specifically happened and what to do. to deal with.

The device sends a high level to the interrupt controller through the interrupt line to tell the operating system that it has generated an interrupt, and the operating system will know which interrupt line generated the interrupt from the status bit of the interrupt controller. The interrupt controller used on the PC is 8259. Each of these controllers can manage 8 interrupt lines. When two 8259s are cascaded, a total of 15 interrupt lines can be controlled. The interrupt lines here are real circuits, and they are connected to the device controller outside the CPU through a hardware interface.

3. IRQ

Not every device can send an interrupt signal to the interrupt line. Only when it has control over a certain interrupt line can it send a signal to this interrupt line. . As computers have more and more external devices, 15 interrupt lines are no longer enough. Interrupt lines are very valuable resources. To use an interrupt line, you must apply for an interrupt line, which is IRQ (Interrupt Requirement). We often refer to applying for an interrupt line as applying for an IRQ or applying for an interrupt number.

IRQ is very precious, so we recommend that you only apply for an IRQ when a device needs an interrupt, or use a shared interrupt method when applying for an IRQ, so that more devices can use interrupts.

No matter whether the IRQ is used exclusively or shared, the process of applying for an IRQ is the same and is divided into 3 steps:

1. Probe all interrupt lines to see which interrupts are not occupied. Select one of these unoccupied interrupts as the IRQ of the device.

2. Apply for the selected IRQ through the interrupt application function. This is to specify whether the application method is exclusive or shared.

3. Determine what to do based on the return value of the interrupt application function: if it succeeds, everything will be fine; if it fails, you will either reapply or give up the application and return an error.

The process of applying for an IRQ is described in detail in the source code attached to the reference book. Readers can have a deep understanding of the application for an interrupt number by carefully reading the short example in the source code.

The above is the in-depth analysis of Linux device driver interrupt (1). For more related content, please pay attention to the PHP Chinese website (www.php.cn)!