the interrupt descriptor table

The CPU constantly has to react to events that arrive without warning — a key is pressed, a network packet lands, a timer fires, or the program itself does something illegal like dividing by zero. For each kind of event the CPU must instantly know which kernel routine to run. The interrupt descriptor table (IDT) is the lookup table that holds those answers: a numbered list where each slot points to the handler for one specific event. Think of it as the emergency call-routing chart at a 911 dispatch center — when a particular type of alarm comes in, the chart says exactly which responder to send, with no time wasted searching.

Concretely, every interrupt and exception has a vector number (0 to 255 on x86). Entry N of the IDT is a descriptor that tells the CPU the address of the handler for vector N and the privilege rules for entering it. When an event fires, the hardware itself looks up that entry, switches into kernel mode, saves enough of the interrupted context (instruction pointer, flags, and so on) onto the kernel stack, and jumps to the handler. The handler does its work, then returns with a special return-from-interrupt instruction that restores the saved state so the interrupted code continues as if nothing happened. Interrupts can nest — a higher-priority interrupt can interrupt a handler — which is why context save/restore must be exact. The kernel tells the CPU where the IDT lives by loading a register (lidt on x86) during early boot.

It matters because the IDT is the single mechanism behind three things that feel different but share the same plumbing: hardware interrupts (asynchronous, from devices), traps (synchronous and intentional, like a system call or a debugger breakpoint), and faults (synchronous and accidental, like a page fault or divide error). A common confusion is treating these as unrelated — they all enter the kernel through an IDT vector; the difference is only their origin and whether the faulting instruction is retried.