Shulou(Shulou.com)06/03 Report--

What this article shares with you is about the delay of handling interrupts and the rules for calling some functions. The editor thinks it is very practical, so I share it with you. I hope you can learn something after reading this article. Let's take a look at it with the editor.

1. Functions with sleep function, such as ioremap,kmalloc,msleep, cannot be used in interrupt handlers. The reason is that interrupt programs are not processes, and there is no concept of process, so there is no concept of sleep.

2. The delay in interrupt handlers can be replaced by busy wait functions, such as ndelay,udelay,mdelay, which are essentially implemented for a certain number of cycles according to CPU frequency; it is best not to use mdelay, because millisecond delay is already very large for the kernel. However, using msleep in interrupt handlers is not possible. (see p210 of the second edition of the linux device driver Development explanation)

3The printk function can be used in interrupt handling functions, but it will take up more time and reduce efficiency. When adjusting the IIC driver, because the IIC read and write processing must be delayed, when I was not using udelay, I used printk to interrupt the normal operation of IIC. When debugging at that time, I found that some printk plus the program was normal, and it was not normal to remove it. It was really unthinkable at that time, but now I understand, so printk takes up a lot of time and just acts as the function of IIC delay. Finally, I removed all the printk and added udelay where the delay was needed to make the program work properly.

4. Using empty loops such as for and while to delay operation in the interrupt handling function, it is found that it can not play the function of delay in the actual test. The linux kernel processes this loop very fast and has no delay effect. This is different from the way bare-board programs use loops to delay.

Other:

1. The interrupt is a kind of electrical signal, which is generated by the hardware device and sent directly to the input pin of the interrupt controller. Then the interrupt controller sends the corresponding signal to the processor. As soon as the processor detects this signal, it interrupts its current work and processes the interrupt. After that, the processor notifies the operating system that an interrupt has been generated, so that the operating system can handle the interrupt appropriately.

2. Different devices correspond to different interrupts, and each interrupt is identified by a unique number. The interrupt value is often referred to as the interrupt request (IRQ) line. Some interrupt values are specified and some are dynamically assigned. A specific interrupt is always associated with a specific device.

3. Different from interrupts, exceptions must be synchronized with the processor clock when they are generated. Exceptions are often referred to as synchronous interrupts. Many processor architectures handle exceptions in a similar way to interrupts, so the kernel handles them similarly.

4. In response to a particular interrupt, the kernel executes a function called an interrupt handler or interrupt service routine. Each device that generates interrupts has a corresponding interrupt handler, and if a device can generate multiple different interrupts, then the device can correspond to multiple interrupt handlers. The interrupt handler of a device is part of its device driver.

5. The real difference between interrupt handlers and other kernel functions is that interrupt handlers are called by the kernel to respond to interrupts, and they run in a special context we call interrupt context.

6. interrupt processing is generally divided into two parts, and the interrupt handler is the upper part-it is executed as soon as an interrupt is received, but only work with a strict time limit is done, which is done when all interrupts are prohibited. Work that can be done later is postponed to the second half. Typically, the lower half is executed as soon as the interrupt handler returns.

7. The interrupt handler in Linux does not need to be reentered. When a given interrupt handler is executing, the corresponding interrupt line is shielded on all processors to prevent another new interrupt from being received on the same interrupt line. Normally, all other interrupts are turned on, so other interrupts on these different interrupt lines can be handled, but the current interrupt line is always disabled. As you can see, the same interrupt handler will never be called at the same time to handle nested interrupts.

8. Shared interrupt handlers are similar to non-shared interrupt handlers in registration and operation, but there are three main differences:

The parameter flags of the registered interrupt handler function request_irq () must set the SA_SHIRQ flag.

The dev_id parameter must be unique for each registered interrupt handler. You cannot pass a null value to a shared handler.

The interrupt handler must be able to tell whether its device is actually causing an interrupt. Otherwise, it has no way of knowing whether its corresponding device issued the interrupt or the other devices that shared the interrupt line issued the interrupt.

9. When an interrupt handler or lower part is executed, the kernel is in the interrupt context. The interrupt context has nothing to do with the process. Because there is no background for the process, the interrupt context cannot sleep. Therefore, certain functions cannot be called from the interrupt context. If a function sleeps, it cannot be used in an interrupt handler. The interrupt context has a strict time limit because it interrupts other code. The code in the interrupt context should be quick and concise, and try not to use loops to handle heavy work. Try to separate the work from the interrupt handler and execute it in the lower half. Interrupt handlers do not have their own stack. Instead, it shares the kernel stack of the interrupted process. If there is no running process, the stack of the idle process is used. The interrupt handler shares someone else's stack, so it must be very economical when it gets space in the stack. The kernel stack is inherently limited, and all kernel code should use it carefully.

10. The Linux kernel provides a set of interfaces for manipulating the interrupt state on the machine. These interfaces provide us with the ability to disable the interrupt system of the current processor or mask an interrupt line of the entire machine. These routines are architecture-related and can be found in and.

In the final analysis, the reason for controlling the interruption of the system is the need to provide synchronization. By banning interrupts, you can ensure that an interrupt handler does not preempt the current code, as well as prevent kernel preemption. However, none of them provides any protection mechanism to prevent concurrent access from other processors. Locks provide protection mechanisms to prevent concurrent access from other processors. Disable interrupts to provide protection mechanisms to prevent concurrent access from other interrupt handlers.

These are the rules for handling delays in interrupts and calling some functions. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.