linux中断简介

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