An interrupt is any service request that causes the CPU to stop its current execution stream and to execute an instruction stream that services the interrupt. When the CPU finishes servicing the interrupt, it returns to the original execution stream at the point where it left off.
Interrupts can be requested from any of the following sources:
Hardware devices use interrupt requests to signal a range of conditions, including device connections, data availability, error conditions, and the completion of device I/O requests. The CPU is responsible for associating an interrupt request with the proper device driver intr(D2) routine based on entries in interrupt vector tables.
The specific needs of interrupt handling routines for driver interfaces are discussed on the intr(D2), intr(D2oddi), intr(D2sdi), intr(D2osdi), and intr(D2mdi) manual pages. See also ``Interrupt sharing''. For information about configuring interrupt handlers on SCO OpenServer 5 systems, see ``Configuring interrupt handlers''.
During system configuration, an ivect (interrupt vector) table is generated and initialized with the address of interrupt handlers corresponding to the various hardware interrupts. For example, based on the entries in the sdevice file shown below, the seventh field in the ivect table will be initialized to lpintr(), the address of the interrupt handler provided by the parallel port driver.
sdevice File for the lp Driver
lp Y 1 3 1 7 378 37F 0 0 -1Conceptually, there exists a single ivect table. However, a per-processor iplmask table and, if proper locking is not provided, critical sections of driver code (base and interrupt) can be executed simultaneously on multiple processors.
On most major Intel x86-based systems, hardware device interrupts are routed through a Programmable Interrupt Controller (PIC) before being serviced by the processor. The typical interrupt processing sequence on x86-based platforms proceeds as follows: