linux中断共享(dev_id的使用)
2014-01-03 14:58
1326 查看
http://www.233.com/linux/fudao/20101119/135604513.html
从个人的理解,Linux2.6内核对中断处理程序的现在的处理可以分为两种模式,一种就是上面说的老的模式(非共享中断线),一种属于使用共享中断线的新模式,从其使用的注册中断处理程序的函数中来分析,函数原型如下:
int request_irq(unsigned int irq,
irqreturn_t (*handler)(int, void *, struct pt_regs *),
unsigned long irqflags,
const char * devname,
void * dev_id);
参数1:中断线号
参数2:中断处理程序函数指针
参数3:标志掩码(SA_INTERRUPT, SA_SAMPLE_RANDOM, SA_SHIRQ)
参数4:用于参数3为SA_SHIRQ(共享中断线)的时候,其他为NULL
原来对于计算机设备比较少的时候,可能一个中断线好可以对应一个中断处理程序(非共享中断线),这时候参数4为NULL,没有任何用,但随着计算机设备的增加,一个中断线号对应一个中断处理程序已经不太现实,这个时候就使用了共享的中断线号,多个设备使用同一个中断线号,同一个中断设备线号的所有处理程序链接成一个链表,这样当在共享中断线号的方式下一个中断产生的时候,就要遍历其对应的处理程序链表,但这个中断是由使用同一个中断线号的多个设备中间的一个产生的,不可能链表里面的所有处理程序都调用一遍吧,呵呵,这个时候就该第四个参数派上用场了。
因为多个设备共享同一个中断线号,当中断产生的时候到底是那一个设备产生的中断呢,这个就取决于第四个参数dev_id,这个参数必须是唯一的,也就是能区分到底是那个设备产生的中断,而且从第二个参数可以看出来,这个参数被传入中断处理程序(第二个参数),可以这么理解,当中断产生的时候,如果是共享的中断线号,则对应链表的所有中断处理程序都被调用,不过在每个中断处理程序的内部首先检查(参数信息以及设备硬件的支持)是不是这个中断处理程序对应的设备产生的中断,如果不是,立即返回,如果是,则处理完成,如果链表中没有一个是,则说明出现错误。
下来说说中断处理程序,先看看原型:
static irqreturn_t intr_handler(int irq, void * dev_id, struct pt_regs * regs);
参数1:中断线号
参数2:设备的信息,唯一确定性
参数3:中断之前的处理器寄存器的信息和状态
通过上面的分析,大概可以看到,参数1(中断线号)貌似有点多余,因为如果是非共享的中断线,通过中断线号直接调用处理程序,将这个参数传进去好像没什么用,如果属于共享的中断线,则通过中断线号直接找到对应的中断处理程序链表,挨个遍历,都是一个中断线号,传进去也没用,该不该调用,通过第二个参数来区分,那为什么要保留这个参数呢?答案是历史遗留问题,往后可能越来越没用了,至于为什么是历史遗留问题,可能在没有第二个参数的时候才在第一个上面做了点手脚,既然第二个参数已经添加进去了,第一个的作用就越来越少了。
如果是共享的中断线号,则对应链表的所有中断处理程序都被调用,不过在每个中断处理程序的内部首先检查(参数信息以及设备硬件的支持)是不是这个中断处理程序对应的设备产生的中断,如果不是,立即返回,如果是,则处理完成,如果链表中没有一个是,则说明出现错误。
从个人的理解,Linux2.6内核对中断处理程序的现在的处理可以分为两种模式,一种就是上面说的老的模式(非共享中断线),一种属于使用共享中断线的新模式,从其使用的注册中断处理程序的函数中来分析,函数原型如下:
int request_irq(unsigned int irq,
irqreturn_t (*handler)(int, void *, struct pt_regs *),
unsigned long irqflags,
const char * devname,
void * dev_id);
参数1:中断线号
参数2:中断处理程序函数指针
参数3:标志掩码(SA_INTERRUPT, SA_SAMPLE_RANDOM, SA_SHIRQ)
参数4:用于参数3为SA_SHIRQ(共享中断线)的时候,其他为NULL
原来对于计算机设备比较少的时候,可能一个中断线好可以对应一个中断处理程序(非共享中断线),这时候参数4为NULL,没有任何用,但随着计算机设备的增加,一个中断线号对应一个中断处理程序已经不太现实,这个时候就使用了共享的中断线号,多个设备使用同一个中断线号,同一个中断设备线号的所有处理程序链接成一个链表,这样当在共享中断线号的方式下一个中断产生的时候,就要遍历其对应的处理程序链表,但这个中断是由使用同一个中断线号的多个设备中间的一个产生的,不可能链表里面的所有处理程序都调用一遍吧,呵呵,这个时候就该第四个参数派上用场了。
因为多个设备共享同一个中断线号,当中断产生的时候到底是那一个设备产生的中断呢,这个就取决于第四个参数dev_id,这个参数必须是唯一的,也就是能区分到底是那个设备产生的中断,而且从第二个参数可以看出来,这个参数被传入中断处理程序(第二个参数),可以这么理解,当中断产生的时候,如果是共享的中断线号,则对应链表的所有中断处理程序都被调用,不过在每个中断处理程序的内部首先检查(参数信息以及设备硬件的支持)是不是这个中断处理程序对应的设备产生的中断,如果不是,立即返回,如果是,则处理完成,如果链表中没有一个是,则说明出现错误。
下来说说中断处理程序,先看看原型:
static irqreturn_t intr_handler(int irq, void * dev_id, struct pt_regs * regs);
参数1:中断线号
参数2:设备的信息,唯一确定性
参数3:中断之前的处理器寄存器的信息和状态
通过上面的分析,大概可以看到,参数1(中断线号)貌似有点多余,因为如果是非共享的中断线,通过中断线号直接调用处理程序,将这个参数传进去好像没什么用,如果属于共享的中断线,则通过中断线号直接找到对应的中断处理程序链表,挨个遍历,都是一个中断线号,传进去也没用,该不该调用,通过第二个参数来区分,那为什么要保留这个参数呢?答案是历史遗留问题,往后可能越来越没用了,至于为什么是历史遗留问题,可能在没有第二个参数的时候才在第一个上面做了点手脚,既然第二个参数已经添加进去了,第一个的作用就越来越少了。
如果是共享的中断线号,则对应链表的所有中断处理程序都被调用,不过在每个中断处理程序的内部首先检查(参数信息以及设备硬件的支持)是不是这个中断处理程序对应的设备产生的中断,如果不是,立即返回,如果是,则处理完成,如果链表中没有一个是,则说明出现错误。
相关文章推荐
- linux中断共享(dev_id的使用)
- linux下共享内存mmap和DMA(直接访问内存)的使用 2014-08-13 09:31:40 blog.chinaunix.net/uid-7374279-id-4413316.html
- 在linux内核里有关共享中断的使用
- linux中断--中断下半部机制的使用 & 中断编程
- 关于PC机Linux (我的是红帽6.3)下使用dnw进行USB下载出现:can not open /dev/secbulk0解决方法
- 在64位linux上安装tomcat、jdk,及使用smb设置文件共享
- Linux目录下/dev/shm的理解和使用
- 5、linux安装分区以及挂载目录的使用来实现ssh公钥的共享
- 从Cortex-M3的MSP 和PSP谈Linux能否在中断中使用Sleep
- Linux与Windows共享文件夹之samba的安装与使用(Ubuntu为例)
- linux进程间通信,使用共享内存方式
- Linux下共享库的制作与使用
- session共享解决办法 ------------------- JSESSIONID不能使用原因
- Linux搭建使用SSH共享存取的 Git Server
- Linux使用Atomicorp的YUM源时提示key ID 4520afa9: NOKEY
- Linux网络编程--使用epoll,共享内存技术实现高性能的聊天室程序
- 【Linux程序设计】之Linux库函数的使用,多文件程序开发,静态与共享函数
- linux使用nfs、portmap服务共享远程磁盘的方法
- Linux(使用了Ubuntu)和windows传输和共享文件的方法总结
- Linux使用mount挂载Windows共享文件夹