Interrupt Service Routine (ISR)

An Interrupt Service Routine (ISR) (aka an Interrupt Handler) is a specialized, high-priority software callback function in the OS kernel or device driver that executes immediately when a specific hardware or software interrupt occurs.

When a device (like a keyboard, hard drive, or network card) signals the CPU that it needs attention, the CPU pauses whatever program it is currently running and jumps directly to the memory address of that device's ISR.

How an ISR Is Registered and Found

During system boot or when a device driver loads, the driver registers its ISR function with the kernel. The kernel stores the memory address of this function in a hardware-accessible table known as the Interrupt Vector Table (IVT).

Hardware Device (e.g. Keyboard)
       │ (Asserts IRQ 1)
       ▼
Interrupt Controller (APIC) ──(Delivers Vector #33)──► CPU
                                                         │
                                   ┌─────────────────────┘
                                   ▼
                   Interrupt Vector Table (IVT)
                   ┌──────────┬────────────────────────┐
                   │ Vector   │ Pointer to ISR Code    │
                   ├──────────┼────────────────────────┤
                   │ ...      │ ...                    │
                   │ 33       │ 0xFFFFFFFF810012A0 ────┼───┐
                   │ ...      │ ...                    │   │
                   └──────────┴────────────────────────┘   │
                                                           │ Jumps to code
                                                           ▼
                                               ┌───────────────────────┐
                                               │ Keyboard ISR Function │
                                               │ (Reads key scancode)  │
                                               └───────────────────────┘

Strict Rules and Constraints of an ISR

Because an ISR hijacks CPU execution asynchronously and interrupts normal program flow, it operates under very strict constraints compared to regular kernel code:

1. Must Execute Extremely Quickly

While an ISR is executing, interrupts of the same (or lower) priority level are typically masked (disabled) by the CPU. If an ISR takes too long to finish, the system will drop incoming signals from other hardware devices, leading to data loss or system freezing.

2. Cannot Sleep, Wait, or Block

Standard kernel code can go to sleep while waiting for memory allocations or file locks. An ISR cannot sleep or block under any circumstances.

• Why? An ISR does not run in the context of a normal process thread; it runs in "Interrupt Context." If an ISR went to sleep, there would be no process thread for the OS scheduler to put to sleep or wake back up, resulting in an immediate kernel panic.

3. Limited API Usage

An ISR can only call special "interrupt-safe" kernel functions. For example, it cannot allocate standard virtual memory (kmalloc with blocking flags) or use blocking synchronization primitives like mutexes. It must use non-blocking spinlocks instead.

4. Must Acknowledge the Hardware

Before finishing, an ISR must tell the hardware device and the Interrupt Controller that the signal was received (often by clearing a hardware register flag or sending an EOI - End of Interrupt signal). Otherwise, the hardware will keep signaling continuously.

Real-World Example: A Keyboard ISR Walkthrough

When you press a key on your physical keyboard:

1. Hardware Event: The keyboard hardware controller generates a hardware interrupt line signal (IRQ 1).

2. Lookup: The CPU looks up entry #33 in the IDT table (which corresponds to IRQ 1) and finds the address of the keyboard driver's ISR (e.g., i8042_interrupt() in Linux).

3. ISR Execution (The "Top Half"):

   • The CPU pauses the active user app and switches to Kernel Mode.
   • The keyboard ISR runs: it reads 1 byte (the physical key scancode) from the keyboard controller's memory port.
   • The ISR places that byte into a kernel ring buffer.
   • The ISR sends an acknowledgment signal back to the controller.

4. Return: The CPU executes an IRET instruction, switching back to User Mode and resuming the paused app right where it left off.

5. Deferred Work: Later, a user-space application (like a text editor) reads the buffered scancode from the kernel via a standard system call.

ISR vs. Normal Kernel Code

in PintOS, pintos/src/threads/interrupt.c has the ISR