TongxinV / oneBook

记录自己的知识框架,有时写写BLOG CSDN博客地址

Home Page:https://blog.csdn.net/TongxinV

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

谈论attribute驱动实现方式(及device_create与设备节点的关系)

TongxinV opened this issue · comments

谈论attribute驱动实现方式(及device_create与设备节点的关系)

目前接触过的两种驱动实现方式是attribute路线和file_operations路线(自己取的)。

attribute的实现方式是学习驱动框架的时候接触到的,如文《驱动框架基础》所示,file_operations方式则比较常见,如文《字符设备驱动基础》中的led驱动实现测试代码。两者都是以led这种简单设备为例子。

blog15-1

blog15-2

分析使用attribute方式的LED驱动框架源码的时候,我们知道了led的一种驱动实现方式--attribute路线。源码中没有register_chrdev,只有class_create和device_create。通过对register_chrdev代码实现的分析,我们知道有register_chrdev一定走的是file_operations路线。详情点击这里:__register_chrdev_region分析

所以猜测attribute路线是一条不依赖于内核维护的255字符设备数组的驱动实现方式。让我困惑的是走attribute方式的LED驱动框架中的device_create的参数设备号0代表什么。我们都知道使用device_create的最大目的是提供相应信息给udev,让udev在用户空间下去创建设备节点以便我们能在用户空间下去访问内核驱动(当然,device_create的作用不仅仅是这个)。

比较之前的file_operations路线实现驱动方式:先使用register_chrdev注册一个设备号,然后使用class_create和device_create来自动创建设备文件节点。那我们现在谈论的attribute方式实现驱动是否也会创建相应的设备文件节点,是否一样能通过设备文件节点来访问到内核空间的驱动?

实际测试发现使用attribute方式的驱动模块leds-s5pv210模块安装后,lsmod控制台会打印出相应的模块安装信息,但是/dev下并没有产生相应的设备节点

所以我的猜测是:虽然给了它一个设备号,但是这个设备号是没有意义的(而且这个设备号是写死在内核源码中,并且当我们用attribute方式去实现一个驱动的时候你不需要像用file_operations方式时那样去指定设备号)。

;真正能解释的就是去看驱动源码,时间有限,没有具体分析源码。留个空再补充

总结:

(1)device_create要能实现自动创建设备节点这一部分作用需要真正的主设备号的存在
(2)使用attribute的驱动实现方式不能通过设备节点来访问内核的对应驱动,只能通过/sys/class/xxx下的属性文件来访问