Kernel Thread Fundamentals¶

Overview¶

Kernel threads provide long-lived execution contexts inside the Linux kernel.

Unlike workqueues, which execute individual jobs and return, kernel threads continuously run and wait for events throughout their lifetime.

Kernel threads are commonly used for:

Protocol state machines
Connection managers
Background services
Event-driven processing
Deferred execution with complex state handling

Typical examples include:

Wi-Fi connection managers
Cellular modem managers
Bluetooth protocol processing
Storage management threads

Kernel Thread Lifecycle¶

A kernel thread is typically created during driver initialization.

kthread_run(...)

The thread continues executing until:

kthread_should_stop()

becomes true.

Driver cleanup requests thread termination using:

kthread_stop(...)

Unlike killing a process, kthread_stop():

Sets the stop flag
Wakes the thread if sleeping
Waits for the thread to exit

Typical thread structure:

static int demo_thread_fn(void *arg)
{
    while (!kthread_should_stop()) {

        ...
    }

    return 0;
}

Polling vs Event Driven Design¶

A simple polling thread:

while (!kthread_should_stop()) {

    process();

    msleep(1000);
}

Although simple, this approach periodically wakes up even when no work exists.

An event-driven design is preferred:

while (!kthread_should_stop()) {

    wait_event(...);

    process();
}

Benefits:

Lower CPU usage
Better power efficiency
Faster event response
Cleaner state-machine integration

Wait Queue Integration¶

Kernel threads are frequently combined with wait queues.

Consumer:

wait_event(
    wq,
    condition);

Producer:

wake_up(&wq);

This resembles RTOS task synchronization:

RTOS
Task + Semaphore/Event

Linux Kernel
Kthread + Wait Queue

Timeout-Based Processing¶

Kernel threads often need timeout handling.

Linux provides:

wait_event_timeout(...)

Possible outcomes:

ret > 0
    Condition satisfied

ret == 0
    Timeout occurred

This allows a thread to react to both:

external events
internal timeout conditions

without polling.

Kernel Thread as an Event Loop¶

Kernel threads naturally fit event-loop architectures.

Typical structure:

while (!kthread_should_stop()) {

    wait_event_timeout(...);

    process_events();

    run_state_machine();
}

Responsibilities:

Thread¶

Provides:

Scheduling context
Sleeping
Wakeup handling
Timeout management

State Machine¶

Provides:

Business logic
Protocol handling
State transitions

Workqueue vs Kernel Thread¶

Workqueue¶

Workqueues execute individual deferred jobs.

Typical flow:

IRQ
    ↓

queue_work()
    ↓

work handler
    ↓

return

Characteristics:

Shared worker threads
Good for short deferred tasks
No persistent execution context

Kernel Thread¶

Kernel threads provide dedicated execution contexts.

Typical flow:

Event
    ↓

Wake Thread
    ↓

Process Event
    ↓

Run State Machine
    ↓

Sleep

Characteristics:

Dedicated thread
Persistent context
Suitable for protocol processing
Suitable for long-lived services

Threaded IRQ vs Workqueue vs Kernel Thread¶

Feature	Threaded IRQ	Workqueue	Kernel Thread
Process Context	Yes	Yes	Yes
Sleep Allowed	Yes	Yes	Yes
Dedicated Thread	IRQ-specific	No	Yes
Long-Lived State Machine	Limited	Moderate	Excellent
Event Loop Design	No	No	Yes
Background Service Pattern	No	Limited	Yes

Design Guidelines¶

Use Threaded IRQ when:

Work originates directly from interrupts
Processing remains relatively short

Use Workqueue when:

Deferred execution is required
Work is independent and short-lived

Use Kernel Thread when:

State machines are involved
Protocol management is required
Long-lived execution context is needed
Multiple event sources must be coordinated

kthread_run()
kthread_should_stop()
kthread_stop()
wait_event()
wait_event_timeout()
wake_up()

Workqueue and Deferred Execution
Completion Synchronization
Wait Queue Internals
Threaded IRQ
Linux Driver Architecture