1. 前言
建议每位linux驱动工程师都花点时间阅读本文。
本文介绍的主题非常实用,能够解答一些困惑,还能让我们的代码变得简单、简洁。先来看一个例子:
相信每个编写过Linux驱动的工程师都曾在probe函数中遇到过类似的问题:需要按照特定顺序申请多种资源(IRQ、Clock、内存、区域、ioremap、DMA等),如果其中一种资源申请失败,就需要回滚并释放之前所有已经申请的资源。因此,函数的结尾通常会有很多goto标签(如exit_free_irq、exit_free_dma等),以便在资源申请失败时小心翼翼地跳转到正确的标签处以释放已申请的资源。
然而,这样的代码充满了大段的重复代码,包含着很多“if (condition) { err = xxx; goto xxx; }”的逻辑,不仅浪费时间,容易出错,还不美观。但是,我们有困惑,就会有改善的余地。最终,Linux设备模型借助设备资源管理(device resource management)为我们解决了这个问题:驱动程序只需要申请资源即可,不必担心如何释放资源,设备模型会为我们处理。最终,我们可以通过以下方式简化驱动程序代码:
怎么做到呢?注意上面“devm_”开头的接口,答案就在那里。不要再使用那些常规的资源申请接口,用devm_xxx的接口代替。为了保持兼容,这些新接口和旧接口的参数保持一致,只是名字前加了“devm_”,并多加一个struct device指针。
2. devm_xxx
下面列举一些常用的资源申请接口,它们由各个framework(如clock、regulator、gpio、等等)基于device resource management实现。使用时,直接忽略“devm_”的前缀,后面剩下的部分,driver工程师都很熟悉。只需记住一点,driver可以只申请,不释放,设备模型会帮忙释放。不过如果为了严谨,在driver remove时,可以主动释放(也有相应的接口,这里没有列出)。
3. 什么是“设备资源”
一个设备能工作,需要依赖很多的外部条件,如供电、时钟等等,这些外部条件称作设备资源(device resouce)。对于现代计算机的体系结构,可能的资源包括:
“
a)power,供电。
b)clock,时钟。
c)memory,内存,在kernel中一般使用kzalloc分配。
d)GPIO,用户和CPU交换简单控制、状态等信息。
e)IRQ,触发中断。
f)DMA,无CPU参与情况下进行数据传输。
g)虚拟地址空间,一般使用ioremap、request_region等分配。
h)等等”
而在Linux kernel的眼中,“资源”的定义更为广义,比如PWM、RTC、Reset,都可以抽象为资源,供driver使用。
在较早的kernel中,系统还不是特别复杂,且各个framework还没有成型,因此大多的资源都由driver自行维护。但随着系统复杂度的增加,driver之间共用资源的情况越来越多,同时电源管理的需求也越来越迫切。于是kernel就将各个resource的管理权收回,基于“device resource management”的框架,由各个framework统一管理,包括分配和回收。
4. device resource management的软件框架
device resource management位于“drivers/base/devres.c”中,它的实现非常简单,为什么呢?因为资源的种类有很多,表现形式也多种多样,而devres不可能一一知情,也就不能进行具体的分配和回收。因此,devres能做的(也是它的唯一功能),就是:
“
提供一种机制,将系统中某个设备的所有资源,以链表的形式,组织起来,以便在driver detach的时候,自动释放。
”
而更为具体的事情,如怎么抽象某一种设备,则由上层的framework负责。这些framework包括:regulator framework(管理power资源),clock framework(管理clock资源),interrupt framework(管理中断资源)、gpio framework(管理gpio资源),pwm framework(管理PWM),等等。
其它的driver,位于这些framework之上,使用它们提供的机制和接口,开发起来就非常方便了。
5. 代码分析
5.1 数据结构
先从struct device开始吧!该结构中有一个名称为“devres_head”的链表头,用于保存该设备申请的所有资源,如下:
那资源的数据结构呢?在“drivers/base/devres.c”中,名称为struct devres,如下:
咋一看非常简单,一个struct devres_node的变量node,一个零长度数组data,但其中有无穷奥妙,让我们继续分析。
node用于将devres组织起来,方便插入到device结构的devres_head链表中,因此一定也有一个list_head(见下面的entry)。另外,资源的存在形式到底是什么,device resource management并不知情,因此需要上层模块提供一个release的回调函数,用于release资源,如下:
抛开用于debug的变量不说,也很简单,一个entry list_head,一个release回调函数。看不出怎么抽象资源啊!别急,奥妙都在data这个零长度数组上面呢。
注1:不知道您是否注意到,devres有关的数据结构,是在devres.c中定义的(是C文件哦!)。换句话说,是对其它模块透明的。这真是优雅的设计(尽量屏蔽细节)!
5.2 一个无关话题:零长度数组
零长度数组的英文原名为Arrays of Length Zero,是GNU C的规范,主要用途是用来作为结构体的最后一个成员,然后用它来访问此结构体对象之后的一段内存(通常是动态分配的内存)。什么意思呢?
以struct devres为例,node变量的长度为3个指针的长度,而struct devres的长度也是3个指针的长度。而data只是一个标记,当有人分配了大于3个指针长度的空间并把它转换为struct devres类型的变量后,我们就可以通过data来访问多出来的memory。也就是说,有了零长度数组data,struct devres结构的长度可以不定,完全依赖于你分配的空间的大小。有什么用呢?
以本文的应用场景为例,多出来的、可通过data访问的空间,正是具体的device resource所占的空间。资源的类型不同,占用的空间的多少也不同,但devres模块的主要功能又是释放资源所占的资源。这是就是零长度数组的功能之一,因为整个memory空间是连续的,因此可以通过释devres指针,释放所有的空间,包括data所指的那片不定长度的、具体资源所用的空间。
零长度数组(data[0]),在不同的C版本中,有不同的实现方案,包括1长度数组(data[1])和不定长度数组(data[],本文所描述就是这一种),具体可参考GCC的规范:
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
5.3 向上层framework提供的接口:devres_alloc/devres_free、devres_add/devres_remove
先看一个使用device resource management的例子(IRQ模块):
前面我们提过,上层的IRQ framework,会提供两个和request_irq/free_irq基本兼容的接口,这两个接口的实现非常简单,就是在原有的实现之上,封装一层devres的操作,如要包括:
1)一个自定义的数据结构(struct irq_devres),用于保存和resource有关的信息(对中断来说,就是IRQ num),如下:
2)一个用于release resource的回调函数(这里的release,和memory无关,例如free IRQ),如下:
“
因为回调函数是由devres模块调用的,由它的参数可知,struct irq_devres变量就是实际的“资源”,但对devres而言,它并不知道该资源的实际形态,因而是void类型指针。也只有这样,devres模块才可以统一的处理所有类型的资源。
”
3)以回调函数、resource的size为参数,调用devres_alloc接口,为resource分配空间。该接口的定义如下:
调用alloc_dr,分配一个struct devres类型的变量,并返回其中的data指针(5.2小节讲过了,data变量实际上是资源的代表)。alloc_dr的定义如下:
看第一句就可以了,在资源size之前,加一个struct devres的size,就是total分配的空间。除去struct devres的,就是资源的(由data指针访问)。之后是初始化struct devres变量的node。
4)调用原来的中断注册接口(这里是request_threaded_irq),注册中断。该步骤和device resource management无关。
5)注册成功后,以设备指针(dev)和资源指针(dr)为参数,调用devres_add,将资源添加到设备的资源链表头(devres_head)中,该接口定义如下:
从资源指针中,取出完整的struct devres指针,调用add_dr接口。add_dr也很简单,把struct devres指针挂到设备的devres_head中即可:
6)如果失败,可以通过devres_free接口释放资源占用的空间,devm_free_irq接口中,会调用devres_destroy接口,将devres从devres_head中移除,并释放资源。这里就不详细描述了。
5.4 向设备模型提供的接口:devres_release_all
这里是重点,用于自动释放资源。
先回忆一下设备模型中probe的流程(可参考“Linux设备模型(5)_device和device driver”),devres_release_all接口被调用的时机有两个:
1)probe失败时,调用过程为(就不详细的贴代码了):
__driver_attach/__device_attach–>driver_probe_device—>really_probe,really_probe调用driver或者bus的probe接口,如果失败(返回值非零,可参考本文开头的例子),则会调用devres_release_all。
2)deriver dettach时(就是driver remove时)
driver_detach/bus_remove_device–>__device_release_driver–>devres_release_all
devres_release_all的实现如下:
以设备指针为参数,直接调用release_nodes:
release_nodes会先调用remove_nodes,将设备所有的struct devres指针从设备的devres_head中移除。然后,调用所有资源的release回调函数(如5.3小节描述的devm_irq_release),回调函数会回收具体的资源(如free_irq)。最后,调用free,释放devres以及资源所占的空间。