request_irq() | 注册中断服务

本文介绍在Linux 2.4和2.6内核中使用request_irq()函数注册中断服务的方法。包括不同内核版本所需的头文件、函数参数含义及宏定义,并提供示例代码。

在 2.4 内核和 2.6内核中都使用 request_irq() 函数来注册中断服务函数。在 2.4 内核中,需要包含的头文件是 #include <linux/sched.h> ,2.6 内核中需要包含的头文件则是
#include <linux/interrupt.h> 。函数原型如下:

  • 2.4 内核

int request_irq (unsigned int irq, void (*handler)(int, void *, struct pt_regs *), unsigned long frags, const char *device, void *dev_id);

  • 2.6 内核

request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, const char *name, void *dev);

参数说明

在发生对应于第 1个参数 irq 的中断时,则调用第 2 个参数 handler 指定的中断服务函数(也就是把 handler() 中断服务函数注册到内核中 )。

第 3 个参数 flags 指定了快速中断或中断共享等中断处理属性。在 2.6 教新的内核里(我的是 2.6.27 ~ 2.6.31 ),在 linux/interrupt.h 中定义操作这个参数的宏如下:

引用
/*
* These flags used only by the kernel as part of the
* irq handling routines.
*
* IRQF_DISABLED - keep irqs disabled when calling the action handler
* IRQF_SAMPLE_RANDOM - irq is used to feed the random generator
* IRQF_SHARED - allow sharing the irq among several devices
* IRQF_PROBE_SHARED - set by callers when they expect sharing mismatches to occur
* IRQF_TIMER - Flag to mark this interrupt as timer interrupt
* IRQF_PERCPU - Interrupt is per cpu
* IRQF_NOBALANCING - Flag to exclude this interrupt from irq balancing
* IRQF_IRQPOLL - Interrupt is used for polling (only the interrupt that is
* registered first in an shared interrupt is considered for
* performance reasons)
*/
#define IRQF_DISABLED 0x00000020
#define IRQF_SAMPLE_RANDOM 0x00000040
#define IRQF_SHARED 0x00000080
#define IRQF_PROBE_SHARED 0x00000100
#define IRQF_TIMER 0x00000200
#define IRQF_PERCPU 0x00000400
#define IRQF_NOBALANCING 0x00000800
#define IRQF_IRQPOLL 0x00001000



早期一点的 2.6 内核这里一般以 SA_ 前缀开头,如:
SA_INTERRUPT 表示禁止其他中断;(对应于 IRQF_DISABLED )
SA_SHIRQ 表示共享相同的中断号 (对应于 IRQF_SHARED )
SA_SAMPLE_RANDOM 此宏会影响到 RANDOM 的处理( 对应于 IRQF_SAMPLE_RANDOM )。

第 4 个参数 name 通常是设备驱动程序的名称。改值用在 /proc/interrupt 系统 (虚拟) 文件上,或内核发生中断错误时使用。

第 5 个参数 dev_id 可作为共享中断时的中断区别参数,也可以用来指定中断服务函数需要参考的数据地址。

返回值
函数运行正常时返回 0 ,否则返回对应错误的负值。

示例代码片段

引用
irqreturn_t xxx_interrupt (int irq, void *dev_id)
{
...

return (IRQ_HANDLED);
}

int xxx_open (struct inode *inode, struct file *filp)
{
if (!request_irq (XXX_IRQ, xxx_interruppt, IRQF_DISABLED, "xxx", NULL)) {

/*正常注册*/
}

return (0);
}

 

<think> 首先,用户的问题是:挂载中断时应该选择使用request_irq还是devm_request_irq?我需要基于提供的引用内容来回答。 回顾引用内容: - [^1] 描述了devm_request_threaded_irq()函数的工作流程,包括如何注册中断顶半部和底半部,以及其自动释放资源的特点。 - [^2] 解释了中断标志如IRQF_TRIGGER_RISING等,并比较了request_irq和devm_request_irqrequest_irq需要手动释放,而devm_request_irq是自动管理的资源,不需要手动free_irq。 - [^3] 讨论了irq domain机制,但这不是直接相关的。 - [^4] 展示了使用request_irq和tasklet的中断处理模板,包括模块加载和卸载函数中的中断申请和释放。 用户的问题焦点是选择request_irq还是devm_request_irq。 关键点: - request_irq:需要手动调用free_irq来释放中断资源。 - devm_request_irq:自动管理资源,当设备移除时自动释放中断资源,减少了资源泄露的风险。 根据引用[^2],devm_request_irq的优势在于它是“managed”资源,避免了手动资源管理错误。 在回答时,我需要: - 使用中文。 - 结构化清晰:逐步解释,帮助用户理解。 - 确保真实可靠,基于引用。 - 生成相关问题。 - 在引用段落末尾添加引用标识,如[^1]。 回答结构: 1. 介绍两种函数。 2. 比较它们的区别。 3. 给出选择建议。 4. 解释理由,基于引用。 5. 生成相关问题。 最后,添加相关问题。 最终输出格式: - 用户可见层:回答清晰。 - 在末尾添加相关问题。 确保LaTeX语法正确:用户问题中没有数学表达式,所以可能不需要。 现在,草拟回答: - 开头解释两者。 - 区别:手动 vs 自动管理。 - 建议:优先使用devm_request_irq以简化代码和避免泄露。 - 引用来源:[^2]明确指出devm_request_irq自动回收资源。 - 示例:引用[^4]使用request_irq,但可以提到devm版本。 相关问题: 1. devm_request_irq是如何实现自动资源管理的? 2. 在共享中断时,request_irq和devm_request_irq有什么注意事项? 3. 如何使用devm_request_threaded_irq注册线程化中断? </think>### 挂载中断时request_irq和devm_request_irq的选择 在Linux内核驱动开发中,挂载中断(即注册中断处理程序)是常见任务。`request_irq`和`devm_request_irq`都是用于申请中断资源的函数,但它们在资源管理方式上有显著区别。下面我将逐步解释两者的区别、选择建议和实际考量。 #### 1. **核心区别:资源管理机制** - **`request_irq`**: - 这是传统的中断申请函数。 - 需要**手动管理资源释放**:在驱动模块卸载或设备移除时,必须显式调用`free_irq`来释放中断资源。 - 使用场景:适用于资源管理需要精确控制的场景,例如在非设备模型驱动或复杂生命周期管理中。 - 示例:引用[^4]展示了在模块卸载函数中手动调用`free_irq`的模板: ```c /*设备驱动模块卸载函数*/ void __exit xxx_exit(void) { ...... /*释放中断*/ free_irq(xxx_irq, xxx_interrupt); // 必须手动释放 } ``` [^4] - **`devm_request_irq`**: - 这是“设备管理”(devres)版本的函数,基于Linux的设备资源管理框架。 - **自动管理资源释放**:当设备(`struct device`)被移除或驱动模块卸载时,内核自动调用释放函数,无需手动`free_irq`。这减少了资源泄露的风险。 - 使用场景:推荐在大多数设备驱动中使用,尤其是支持热插拔或资源管理简化的场景。 - 关键优势:如引用[^2]所述,`devm_request_irq`是申请的内核“managed”资源,自动回收资源: > devm_request_irqrequest_irq区别在于前者是申请的内核“managed”资源,不需要自己手动释放,会自动回收资源,而后者需要手动调用free_irq来释放中断资源 [^2]。 #### 2. **选择建议** - **优先选择`devm_request_irq`**: - 在大多数现代驱动开发中,`devm_request_irq`是更好的选择,因为它简化了代码并降低了资源泄露的可能性。尤其当驱动与设备模型(如`platform_device`)集成时,它能自动处理资源释放,提高代码可靠性。 - 例如,在热插拔设备或动态加载模块的场景中,自动管理能避免忘记释放中断导致的系统不稳定。 - **何时使用`request_irq`**: - 在以下情况下可能需要手动管理: - 驱动不依赖Linux设备模型(例如,某些旧式或自定义驱动)。 - 需要精细控制中断生命周期(例如,在运行时动态启用/禁用中断多次)。 - 共享中断(`IRQF_SHARED`标志)时,某些复杂场景可能需要手动介入 [^2]。 - **性能与兼容性**: - 两者在中断处理性能上无显著差异,因为核心处理逻辑相同。 - `devm_request_irq`内部调用`request_irq`,但添加了资源跟踪机制 [^1]。 #### 3. **实际使用注意事项** - **中断标志设置**:无论选择哪个函数,都需要正确设置中断标志(如`IRQF_TRIGGER_RISING`用于上升沿触发),这些标志定义在引用[^2]中 [^2]。 - **错误处理**: - `devm_request_irq`在错误时自动清理,而`request_irq`需在失败时手动回滚资源。 - 示例:使用`devm_request_irq`时,驱动模块卸载函数可以省略`free_irq`,代码更简洁。 - **线程化中断**:如果使用线程化中断(顶半部+底半部),`devm_request_threaded_irq`是更安全的自动管理版本 [^1]。 #### 总结 - **推荐`devm_request_irq`**:除非有特定需求(如精细资源控制),否则优先使用它以简化开发和维护。 - **理由**:自动资源管理减少了常见错误(如资源泄露),并符合现代Linux驱动的最佳实践。 如果您有具体代码上下文或驱动类型,我可以提供更针对性的建议。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值