1、中斷標識碼（中斷類型號）、中斷向量、中斷向量表
中斷類型號：由硬件（通常是中斷控制器）產生，以標識不同的中斷源；
中斷向量：中斷服務程序入口地址；
中斷向量地址 = 中斷類型號 × 4；（每個中斷向量佔4個字節）
中斷向量表即中斷描述符表（Interrupt Descriptor Table, IDT）,保存256箇中斷向量（80x86對應有256箇中斷，每個中斷都對應一箇中斷處理程序）。
2、中斷向量表的加載過程：
CPU根據中斷號獲取中斷向量的值，即對應中斷服務程序的入口值。因此，爲了讓CPU由中斷號查找到對應的中斷向量，就需要在內存中建立一張查詢表，即中斷向量表（32位保護模式下稱爲中斷描述符表IDT）。80x86微機包含256箇中斷，每個中斷對應一箇中斷服務處理程序。默認的中斷服務處理程序在BOIS中給出，在80X86微機啓動時，ROM BOIS中的程序會在物理內存開始地址0x0000:0x0000初始化並設置中斷向量表。而在系統引導加載操作系統時會根據實際需要修改某些中斷向量的值，比如Linux，除了在剛開始加載內核時用到BOIS提供的顯示和磁盤讀操作中斷功能，在內核正常運行之前則會重新設置一張中斷向量表（中斷描述符表），完全拋棄了BOIS所提供的中斷服務功能。
3、中斷上下文
中斷髮生以後，CPU跳到內核設置好的中斷處理代碼中去，由這部分內核代碼來處理中斷。這個處理過程中的上下文就是中斷上下文。
中斷上下文不是一個進程，它並不存在task_struct，所以它是不可調度的。所以中斷上下文就不能睡眠。
那麼，中斷上下文爲什麼不存在對應的task_struct結構呢？中斷的產生是很頻繁的，並且中斷處理過程很快。如果中斷上下文維護一個對應的task_struct結構，那麼這個結構頻繁地分配、回收、並且影響調度器的管理，這樣會對整個系統的吞吐量造成影響。
中斷上下文中不能執行如下操作：
Go to sleep or relinquish the processor
Acquire a mutex
Perform time-consuming tasks
Access user space virtual memory