Events transfer control to a handler
Events such as I/O completion or a timer expiry can direct a processor to a configured handler. The system need not wait for the user program to make a service call before handling them.
Entry must preserve state and establish the required environment. Handling can end by resuming the original task or lead to other scheduled work. The arrival of an interrupt is not itself a task context switch.
Separating controller details from handling flow
Linux’s generic IRQ layer separates driver APIs, high-level flow handlers, and controller-specific operations. Drivers register handling through common interfaces while architecture and controller code deliver the event.
Edge-triggered and level-triggered sources can require different acknowledgement, masking, and completion flows. Those operations have different roles, so a single universal controller sequence would be misleading.
References: [4]
Handling context imposes constraints
An interrupt can arrive during user execution or while the kernel is already active, requiring different state handling. Non-maskable or similar events can even interrupt entry paths, making nesting and reentrancy relevant.
Interrupt code therefore needs context-aware design. Interfaces such as Linux threaded IRQs provide different arrangements for handling work. Permitted behavior follows the selected interface and context rather than one rule for every event source.