问一个设备驱动模型的问题

tempname3

2.6的设备模型里是谁来注册device的？对应驱动代码里？那样的话把device和driver分开就没意义了吧。像platform_device那静态分配，bus的match方法只是走走过场而已，感觉像是被强行嵌入到设备驱动模型里。device与driver可以分开的话，假设driver先注册了，谁来注册device呢？比如USB或者PCI总线，每当一个新设备出现了，其对应的device结构体是由谁来生成？

amarant

大概是因为有时候一个驱动会应用到很多设备上吧。我这边的代码是，设备在板子BSP的代码上注册，驱动在响应的实现里注册。

tempname3

那就是静态注册啊。如果内核编译好了后，总线上又增加了同样的设备，系统里是确实有相应驱动，但是device的生成与注册、设备和驱动的匹配与绑定，这些过程是由什么触发的呢？

amarant

这些我也一直想了解，没看到什么资料介绍这些的。。

tempname3

比如，一个USB设备，系统中存在对应驱动，当设备插入系统中，硬件上可能有某种方法检测到它的存在。内核的USB层依照USB协议可以获得设备的信息，总线驱动再依据这些信息生成对应的device结构体，将其注册到系统中。然后标准设备驱动模型就照那一套流程来绑定设备与驱动。PCI兴许也是这样。两种总线我都不了解，不知道是否如此。

但是上述情况出现在I2C这样的总线上就没办法了。就算是有相应的设备驱动，由于I2C总线没有办法获取设备的信息，几乎不能向标准设备驱动模型提供什么线索，无法生成device结构体并注册，也就没有查找对应驱动这一环节。所以I2C的设备信息只能静态地声明，新增一个设备，就得通过某种方式手工向内核提供其硬件信息。但I2C里有个通过地址探测设备的环节，又有点那种自动检测的味道。或者应该说，如果地址是唯一必要的信息，那么I2C设备就跟USB设备类似，由总线层负责创建device结构体并注册；如果驱动需要其它信息才能操纵设备，那就只能通过模块之类的方式人工向内核提供设备信息。

有没有人确认一下呀。。。。。。

kamingli

driver 是用来驱动device的, 因此, 要么在kernel的编译时,就准备好device, 或在驱动加载时动态加入.

chiwq

2.6的设备模型里是谁来注册device的？对应驱动代码里？那样的话把device和driver分开就没意义了吧。像platf ...
tempname3 发表于 2011-04-19 16:03

所有的操作都是driver完成，只是driver不同，
所有的driver执行都是由内核编译时将入口放置到一个特定的section中，排序执行

   
设备的发现和注册：基于ACPI描述，由ACPI的driver完成
其他具体设备的驱动在执行时查找本driver支持的设备，使得driver和deivce关联起来

tempname3

所有的操作都是driver完成，只是driver不同，
所有的driver执行都是由内核编译时将入口放置到一个特 ...
chiwq 发表于 2011-04-22 09:13

如果设备后于驱动出现在系统中，那表设备的device结构体是谁来创造与注册的呢？注册之后才能匹配到驱动吧。

chiwq

如果设备后于驱动出现在系统中，那表设备的device结构体是谁来创造与注册的呢？注册之后才能匹配到驱动 ...
tempname3 发表于 2011-04-22 09:34

   
两种情况：
１、hotplug:加了设备不重新启动，由hotplug机制负责添加设备、搜索驱动；
2、重启系统：这就简单了，BIOS会发现新的设备，将描述提交给OS，然后OS跟往常一样，。。。。。

tempname3

回复 9# chiwq

哦。也就是说，USB设备添加以后，hotplug层负责创建device并注册。PCI设备添加以后，BIOS自检时查到设备，提供设备信息，内核某部分的初始化代码根据这些信息创建device结构体并注册。两种方式都行不通的话，程序员静态地提供设备信息，平台初始化代码里根据这些信息生成并注册device。