| 1, interrupt is an electrical signal, generated by hardware devices, and directly into the interrupt controller input pin. The interrupt controller then sends the corresponding signal to the processor. Once the processor detects this signal, it interrupts its current work instead of processing the interrupt. Thereafter, the processor notifies the operating system that an interrupt has been generated, so that the operating system can properly handle the interrupt. 2, different devices correspond to different interrupts, and each interrupt is through a unique digital ID. Break values are often referred to as interrupt request (IRQ) lines. Some of the interrupt values are specified, and some are dynamically allocated. A specific interrupt is always associated with a particular device. 3, the exception is different from the interrupt, it must be considered in the production with the processor clock synchronization. Exceptions are often referred to as synchronous interrupts. Many processor architectures handle exceptions in a similar manner to interrupts, so the kernel handles them similarly. 4, in response to a specific interrupt, the kernel executes a function called an interrupt handler or interrupt service routine. Each device that produces interrupts has a corresponding interrupt handler, and if a device can produce many different interrupts, the device can correspond to multiple interrupt handlers. An interrupt handler for a device is part of its device driver. 5, the real difference between interrupt handlers and other kernel functions is that the interrupt handlers are called by the kernel to respond to interrupts, and they run in the special context we call the interrupt context. &NBSP;&NBSP;&NBSP;6, interrupt processing is generally divided into two parts, the interrupt handler is the upper half-receive an interrupt to execute immediately, but only to do with strict time limit work, these jobs are all interrupted by the case of the completion. The work that can be allowed to be done later is postponed to the lower half. Typically, the lower half executes immediately when an interrupt handler returns. 7, interrupt handlers in Linux are not required to be reentrant. When a given interrupt handler is executing, the corresponding disconnection is blocked on all processors to prevent another new interrupt from being received on the same interrupt line. Normally, all other interrupts are open, so other interrupts on these different interrupts can be processed, but the current disconnection is always prohibited. As you can see, the same interrupt handler is never invoked at the same time to handle nested interrupts. 8, the sharing of interrupt handlers and unshared in the registration and operation of a similar, but the difference is mainly in the following three places: noteThe parameters of the book Interrupt handler function REQUEST_IRQ () flags must be set SA_SHIRQ flags. for each registered interrupt handler, the dev_id parameter must be unique. You cannot pass a null value to a shared handler. The interrupt handler must be able to distinguish whether its device has really interrupted. Otherwise it could not know whether it was the device that sent the interrupt or the other device that shared the break line. 9. When executing an interrupt handler or the lower half, the kernel is in the interrupt context. Breaking contexts and processes has nothing to do with it. Because there is no background of the process, the interrupt context is not able to sleep. Therefore, some functions cannot be called from the interrupt context. If a function sleeps, it cannot be used in an interrupt handler function. The interrupt context has a more stringent 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 put it in the lower half of the execution. An interrupt handler does not have its own stack. Instead, it shares the kernel stack of the interrupted process. If there are no running processes, use the stack of the idle process. An interrupt handler shares someone else's stack, so it must be very economical to get space on the stack. The kernel stack is very limited, and all kernel code should use it sparingly. 10. The Linux kernel provides a set of interfaces to operate the interrupt state on the machine. These interfaces provide us with the ability to disable the current processor's interrupt system, or to block a single interrupt line from the entire machine, which is related to architecture and can be found in <asm/system.h> and <asm/irq.h>. 11. The reason for controlling the interrupt system is the need to provide synchronization. By prohibiting interrupts, you can ensure that an interrupt handler does not preempt the current code, and that it can prevent kernel preemption. None of them provide any protection against concurrent access from other processors. Locks provide protection against concurrent access from other processors. Disables the provision of protection to prevent concurrent access from other interrupt handlers. |
