为何操作系统内核需多个Interrupt Handler而非仅单个？

Great question—let’s break this down like we’re debugging a tricky kernel issue over coffee. Relying on a single interrupt handler just doesn’t work for how modern operating systems interact with hardware and processes, and here’s why:

Why a Single Interrupt Handler Won’t Cut It #

• Hardware diversity is non-negotiable: Every I/O device (keyboard, disk, network card) has entirely unique signaling and service needs. A keyboard sends interrupts when keys are pressed—you need to read scan codes and map them to characters. A disk fires an interrupt when it finishes a read/write—you need to fetch data from its buffer and wake waiting processes. A single handler would have to check every possible device on every interrupt, which is insanely slow and inefficient.
• Interrupt priorities can’t be enforced: Some interrupts are way more urgent than others. A power failure interrupt needs immediate action to save data, while a mouse movement can wait a few cycles. A single handler would treat all interrupts equally, leading to critical events being delayed by trivial ones.
• Massive context switching overhead: A monolithic handler would be thousands of lines long, jumping between device-specific logic constantly. This would cause huge cache misses and drag down overall system performance, since interrupts pause normal process execution.

Key Differences Between Interrupt Handlers #

Interrupt handlers aren’t just "different functions"—they’re tailored to their specific use cases, with core differences like:

• Device-specific logic: A network card handler manages packet reception/transmission and interacts with the network stack, while a serial port handler deals with byte-stream I/O. These operations are completely unrelated.
• Trigger behavior handling: Some interrupts are edge-triggered (fire once when a signal changes state), others are level-triggered (stay active until the device is acknowledged). Handlers must account for this—level-triggered handlers have to clear the interrupt signal before returning, otherwise the CPU will loop on the same interrupt indefinitely.
• Resource and subsystem integration: A disk handler works with the block I/O subsystem and request queues, while a keyboard handler talks to the input subsystem and event buffers. They use distinct kernel data structures and have unique locking requirements to avoid race conditions.
• Deferred work handling: Some handlers can acknowledge the interrupt and return immediately, scheduling non-urgent tasks (like tasklets or workqueues in Linux) to run later. Others need to handle all work inline—this depends entirely on the device’s needs.

Why Multiple Handlers Are a Must #

• Performance optimization: Each handler is lean and focused, so it runs as quickly as possible. This minimizes the time the CPU spends in interrupt context, which is critical because interrupts block normal process execution.
• Maintainability: Imagine debugging a keyboard issue in a 10,000-line monolithic handler vs. a 200-line dedicated keyboard handler. Separation of concerns makes code easier to write, test, and fix—no more hunting through unrelated logic to find a bug.
• Scalability: Adding a new device (like a new sensor or GPU) just requires writing a new handler and hooking it into the interrupt table. No need to modify existing code, which is how kernel modules enable OSes to support new hardware without full rewrites.
• Correctness and reliability: Different devices have unique error-handling needs. A network card might need to retransmit a packet on an error interrupt, while a disk might mark a sector as bad. Mixing these paths in a single handler would lead to bugs, instability, and data loss.

内容的提问来源于stack exchange，提问作者Dragneel