= Interrupt
{wiki}
An <interrupt> redirects <CPU> execution to an <interrupt handler> in response to an event. Here the main case is an asynchronous hardware <interrupt>: a timer or device requests attention independently of the instruction currently being executed. A device completing a receive operation can announce that its data is ready while the <CPU> is running another program. <Interrupt-driven input-output> illustrates this with an explicit timeline. https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf[Arpaci-Dusseau and Arpaci-Dusseau, OSTEP chapter 6, section 6.3: timer interrupts and regaining control]{ref}
A <synchronous processor exception>, such as a <page fault> caused by a particular memory access, is tied to instruction execution. A <system call> is an intentional program request for an <operating-system kernel> service. These routes can share entry machinery, and an instruction named a software interrupt can implement a <system call>, but this does not make that request an asynchronous device event. For example, the <Linux kernel> on <x86> documents separate entries for external <interrupts>, divide exceptions, `syscall` and `int 0x80`. https://docs.kernel.org/arch/x86/entry_64.html[Linux kernel documentation, Kernel Entries: interrupt, exception and system-call entry points]{ref}
The usual device route is a request through an <interrupt controller>, architecture-specific entry, and dispatch to an <interrupt handler>. In the <Linux kernel>, generic handling separates controller operations from flow handling and <device driver> callbacks. Requests can arrive through a pin or a message, and several devices can share a request source. Routing, priorities and <interrupt masking> determine which requests can be delivered; notification therefore need not mean immediate execution of the <interrupt handler>. https://docs.kernel.org/core-api/genericirq.html[Linux kernel documentation, generic IRQ handling: abstraction layers and interrupt control flow]{ref}https://docs.kernel.org/core-api/irq/concepts.html[Linux kernel documentation, What is an IRQ?: pin and packet requests, shared sources]{ref}
The <CPU> and entry code preserve the state needed to resume interrupted execution, including the <instruction pointer>. Handling may enter a higher <processor privilege level> when interrupting ordinary program execution, but an <interrupt> can also arrive while privileged code is already running. The protected entry route and handler placement depend on the architecture and <operating system>; a <microkernel> need not place all <device driver> work where a <monolithic kernel> does. An <interrupt> entry is also distinct from a <context switch> to another <operating-system process>. https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf[Arpaci-Dusseau and Arpaci-Dusseau, OSTEP chapter 6, sections 6.2–6.3: protected entry, saved state and switching]{ref}https://docs.kernel.org/arch/x86/entry_64.html[Linux kernel documentation, Kernel Entries: entry from user mode and already executing kernel code]{ref}
// Target: computer-science.bigb
Back to article page
