Detailed explanation of kthread_run function
Take the creation of PCIE hot-swappable kernel threads as an example. Note
: Kernel threads are slightly different from RTOS threads. Here, Linux runs directly after creation. Some RTOS threads need to be added to the scheduling queue before they can be executed, such as RT-Thread. system
kthread_run is a function in the Linux kernel for creating and running kernel threads (Kernel Thread).
In the Linux kernel, a thread is a lightweight execution unit that can run independently and share process resources. Unlike user space threads (User Space Thread), kernel threads run in the kernel state, with higher privilege levels and wider access to system resources.
The function of the kthread_run function is to create a new kernel thread and automatically add it to the kernel thread scheduler for scheduling. It accepts two parameters: threadfn and data.
threadfn is a function pointer representing the function to be executed in the new thread. This function should have no parameters and return type int. Usually, developers will write the code logic that the new thread needs to execute in the threadfn function.
data is a pointer representing the parameters passed to the threadfn function. Developers can use the data parameter to pass custom data structures or other information to the new thread.
The kthread_run function creates a new kernel thread and uses the specified threadfn function as the entry point for the new thread. Then, the new thread starts executing the code in the threadfn function. Developers can write custom logic in threadfn, such as performing certain tasks, handling interrupts, driving hardware, etc.
kthread_run is a function used to create and run kernel threads, it accepts a function pointer as the thread entry, and can pass parameters to the thread function. By using kthread_run, developers can create and manage their own threads in the Linux kernel to implement various types of asynchronous task processing and concurrent operations.
schedule_timeout_idle Execute timeout scheduling function in idle state
effect
Normally, when a task calls a schedule_timeoutfunction to sleep, it will be considered as a load contributor, which will have an impact on the system's load average. However, some specific tasks may wish not to be counted as part of the system load during sleep;
/*
* Like schedule_timeout_uninterruptible(), except this task will not contribute
* to load average.
*/
signed long __sched schedule_timeout_idle(signed long timeout)
{
__set_current_state(TASK_IDLE);
return schedule_timeout(timeout);
}
In schedule_timeout_idlethe function, first call __set_current_statethe function to set the status of the current task to TASK_IDLE, indicating that the task is in an idle state. Then, schedule_timeoutsleep for the specified timeout by calling the function.
schedule_timeoutThe function will suspend the current task and decide when the task will be woken up according to the specified timeout (in ticks). When the timeout expires or other events that cause the task to wake up occur, the suspended task will be rescheduled for execution.
schedule_timeout_idlefunction is a special sleep function that sets the state of the current task to TASK_IDLE so that the task is not counted as part of the system load during sleep. It is then used with the standard schedule_timeout function to sleep and reschedule within the specified timeout.
request_threaded_irq request thread interrupt
Used to request an interrupt with threaded processing
*/
int request_threaded_irq(unsigned int irq, irq_handler_t handler,
irq_handler_t thread_fn, unsigned long irqflags,
const char *devname, void *dev_id)
{
The parameters are described as follows:
irq: The interrupt number to request. handler: Pointer to the top half (top half) interrupt handler function pointer. When an interrupt is triggered, the kernel calls this handler for fast interrupt handling.
thread_fn: function pointer to the bottom half (bottom half) interrupt handler. When an interrupt is triggered, the kernel creates a kernel thread and schedules the handler for execution. This thread will run out of interrupt context and can perform some lengthy or sleep-requiring processing operations.
irqflags: Interrupt flags, used to specify the attributes and behavior of interrupt requests. It can be set using a predefined interrupt flag macro.
devname: Device name, used to identify the device requesting interrupt. dev_id: Device ID, the parameter that will be passed to the interrupt handler.
The request_threaded_irq function is used to request an interrupt with threaded processing, and
associate the interrupt processing function handler and the bottom half processing function thread_fn to the interrupt respectively. In this way, when an interrupt is triggered, the top-half handler will be called first for fast interrupt response, and then the kernel will create a kernel thread and schedule the execution of the bottom-half handler to complete longer or sleep-requiring processing operations.This threaded interrupt processing mechanism can improve the real-time and scalability of interrupt processing, so that the interrupt processing function can perform complex operations more flexibly without blocking the execution of other important tasks.
Limitations and Considerations for Shared Interrupts
1. The shared interrupt needs to pass a real device ID (dev-ID) as a parameter. If the real device ID is not provided, it will be difficult to determine which interrupt corresponds to which device, which may cause problems such as interrupt release logic.
2. Disabling auto enable is not compatible with shared interrupts. In the disabled state, shared interrupts may request to be enabled and then wait forever for the interrupt to arrive, causing problems.
3. IRQF_COND_SUSPEND is meaningful only when interrupts are shared, and cannot be set at the same time as IRQF_NO_SUSPEND. IRQF_COND_SUSPEND is used to interrupt the conditional processing during suspend, which means that the interrupt will be suspended only when certain conditions are met. And IRQF_NO_SUSPEND means that the interrupt will not be suspended.
The above notes illustrate some limitations and usage considerations for shared interrupts. These requirements need to be met to ensure correctness and reliability of shared interrupts.