Interrupts in the Linux kernel

http://blog.csdn.net/weiqing1981127/article/details/8298585

The interrupt handler is used by the kernel to respond to interrupts, it runs in the interrupt context, the interrupt handler is the top half, and when an interrupt is received, it starts execution immediately, but only with strict deadlines, such as answering the received interrupts or resetting the hardware, which is done with all interrupts blocked. Work that can be allowed to be done later is postponed to the lower part.

The registration of an interrupt handler is through the REQUEST_IRQ function, which cannot be called in the interrupt context or other code that does not allow blocking because there is an operation that allocates memory inside the function. interrupt handlers in Linux are not required to be re-entered, because when a given interrupt handler is executing, all other interrupts are open and the current break is always forbidden, so the same interrupt handler is never called at the same time to handle nested interrupts. Interrupt handlers do not care about the settings of the interrupt stack and kernel stack, so save the kernel stack space as much as possible.

Locks provide protection against concurrent access from other processors, while the protection mechanism provided by the prohibit interrupt is to prevent concurrent access from other interrupt handlers. Prohibit interrupts include prohibiting all interrupts of the current processor and prohibiting one interrupt line two, all interrupts can use the local_irq_save and local_irq_restore functions, prohibit a middle line can be used Disable_ The IRQ function.

View the interrupt numbers used can be obtained with cat/proc/interrupts. the state of the interrupt system can be obtained through several functions,irqs_disabled function to see whether local interrupt delivery is forbidden, andin_interrupt function to see if the context is interrupted; IN_IRQ To see if the interrupt handler is currently executing .

Why do you want to introduce the second half? Because the upper part of the interrupt processing process has some limitations: one, interrupts are executed asynchronously, it is possible to interrupt other important code, and in order to avoid interruptions, the interrupt handler should execute faster. Second, if there is currently an interrupt handler is executing, it is necessary to do an operation to prohibit other interrupts, the hardware and the operating system can not communicate after the interruption, so there is also interrupt processing faster. Third, interrupt processing often requires hardware operation, so also need to hurry. Four, the interrupt handler is not in the process context and cannot sleep, which limits what they do.

The lower part of the task is to perform work that is closely related to interrupt handling that the interrupt handler itself does not perform. Interrupt handlers often need to confirm the arrival of the interrupt through the operating hardware, and sometimes it copies the data from the hardware. We will be very sensitive to time, hardware-related, to ensure that other interrupts are not interrupted by the execution of the interrupt handler, other tasks are considered to be placed in the lower half of the execution. The key to the bottom half of the execution is to run all of the interrupts as they run.

In the 2.6 kernel version, the lower half implements mechanisms including soft interrupts,Tasklet, and work queues.

Soft interrupts are a set of statically defined lower-half interfaces, 32, which can be executed concurrently on the processor, and soft interrupts must be statically registered during compilation, where soft interrupts are not soft interrupts mentioned in the system call. soft interrupts are performed in the following places : First, when a hardware interrupt code is returned. Second, in the ksoftirqd kernel thread (each processor has a set of kernel threads that can handle soft interrupts and Tasklet, when a large number of soft interrupts occur, the kernel wakes up a set of kernel threads to handle the load, which is the kernel thread ksoftirqd thread ). Third, in those code that explicitly checks and executes the software interrupts, such as the network subsystem. Only the network and SCSI subsystems use soft interrupts directly, and soft interrupts are the right choice for applications where the world is demanding and able to perform lock-up work efficiently.

Tasklet has two kinds of soft interrupts represented:HI_SOFTIRQ andTASKLET_SOFTIRQ, the former has a higher priority. All theTasklet all through repeated useHI_SOFTIRQ andtasklet_softirq These two soft interrupts are implemented. When a tasklet is invoked, the kernel wakes one of the two soft interrupts, which is then handled by a particular function, executing all the scheduled tasklet, this function guarantees that only a given class of tasklet will be executed. tasklet cannot sleep, which means you cannot be tasklet runtime allows response interruption, so you must do well to prevent (such as shielding interrupts then get a lock tasklet_disable function prohibits a specified tasklet, you can also use tasklet_ Kill removes a tasklet from the Suspended queue.

Declare_tasklet (test_tasklet,test_tasklet_func,0); Defined

void Test_tasklet_func (void)//processing function

{

PRINTK ("Tasklet is executing!\n");

}

Tasklet_schedule (&test_tasklet); Scheduling

The work queue can be pushed back to a kernel thread to execute, the bottom half is always executed in the context of the process, the Task Scheduler is running reschedule or even sleep, it is the only implementation mechanism that can run in the context of the process, and only it can sleep . Although the action handler is running in the process context, it cannot access the user space because the kernel thread does not have a related memory mapping in user space, and the kernel will typically run on behalf of the user space only when a system call occurs.

The Work queue subsystem provides a default worker thread, as long as the task that needs to be deferred is given to a particular generic thread, and the default worker thread is called events/n, which we generally use as the default worker thread, but if you need to do a lot of processing in a worker thread , it's even better to create your own worker threads. Each CPU of the system has a worker thread, each worker thread is represented by the struct cpu_workqueue_struct struct, and the struct workqueue_struct represents the given type ( That is the same type ) for all worker threads.

Init_work (&button_dev->work, gpio_keys_report_event); Defined

static void Gpio_keys_report_event (struct work_struct *work)//Processing function

{

Key_values[0] = ' 0 '; Clear key identification

Input_report_key (channel, BTN_0,!!)  ev_press); reporting key events to the input subsystem

Input_sync (channel); Synchronous operation

ev_press = 0; Clear Key values

}

Schedule_work (&button_dev->work); Scheduling Work Queue processing functions

Cancel_work_sync (&button_dev->work); Delete Work queue

Tasklet is based on software interrupts, and work queues are implemented by kernel threads, and if you have hibernation, then you use the work queue, otherwise it is best to use the tasklet mechanism. To ensure that data is shared, a lock is generally obtained first, and then the lower half is suppressed using the Local_bh_disable function, but the local_bh_disable function does not prohibit the execution of the work queue because the work queue does not involve asynchronous execution, but because of soft interrupts and Tasklet are sent asynchronously, so the kernel must disallow them.

Interrupts in the Linux kernel