设备模型拍得再玄幻,它也只是个模型,必须得落实在具体的子系统,否则就只能抱着个最佳技术奖空遗恨。既然前面已经以USB子系统的实现分析示例了分析内核源码应该如何入手,那么这里就仍然以USB子系统为例,看看设备模型是如何软着陆的。
内核中USB子系统的结构
我们已经知道了USB子系统的代码都位于drivers/usb目录下面,也认识了一个很重要的目录——core子目录。现在,我们再来看一个很重要的模块——usbcore。你可以使用“lsmod”命令看一下,在显示的结果里能够找到有一个模块叫做usbcore。
localhost:/usr/src/linux-2.6.23/drivers/usb/core # lsmod
Module Size Used by
af_packet 55820 2
raw 89504 0
nfs 230840 2
lockd 87536 2 nfs
nfs_acl 20352 1 nfs
sunrpc 172360 4 nfs,lockd,nfs_acl
ipv6 329728 36
button 24224 0
battery 27272 0
ac 22152 0
apparmor 73760 0
aamatch_pcre 30720 1 apparmor
loop 32784 0
usbhid 60832 0
dm_mod 77232 0
ide_cd 57120 0
hw_random 22440 0
ehci_hcd 47624 0
cdrom 52392 1 ide_cd
uhci_hcd 48544 0
shpchp 61984 0
bnx2 157296 0
usbcore 149288 4 usbhid,ehci_hcd,uhci_hcd
e1000 130872 0
pci_hotplug 44800 1 shpchp
reiserfs 239616 2
edd 26760 0
fan 21896 0
⋯⋯
找到了usbcore那一行吗?core就是核心,基本上你要在你的电脑里用USB设备,那么两个模块是必须的:一个是usbcore,这就是核心 模块;另一个是主机控制器的驱动程序,比如这里usbcore那一行我们看到的ehci_hcd和uhci_hcd,你的USB设备要工作,合适的USB 主机控制器模块也是必不可少的。
usbcore负责实现一些核心的功能,为别的设备驱动程序提供服务,提供一个用于访问和控制USB硬件的接口,而不用去考虑系统当前存在哪种主机控制器。至于core、主机控制器和USB驱动三者之间的关系,如下图所示。
USB 驱动和主机控制器就像core的两个保镖,协议里也说了,主机控制器的驱动(HCD)必须位于USB软件的最下一层。HCD提供主机控制器硬件的抽象,隐 藏硬件的细节,在主机控制器之下是物理的USB及所有与之连接的USB设备。而HCD只有一个客户,对一个人负责,就是usbcore。usbcore将 用户的请求映射到相关的HCD,用户不能直接访问HCD。
core为咱们完成了大部分的工作,因此咱们写USB驱动的时候,只能调用core的接口,core会将咱们的请求发送给相应的HCD。
USB子系统与设备模型
关于设备模型,最主要的问题就是,bus、device、driver是如何建立联系的?换言之,这三个数据结构中的指针是如何被赋值的?绝对不可 能发生的事情是,一旦为一条总线申请了一个struct bus_type的数据结构之后,它就知道它的devices链表和drivers链表会包含哪些东西,这些东西一定不会是先天就有的,只能是后天填进来 的。
具体到USB子系统,完成这个工作的就是USB core。USB core的代码会进行整个USB系统的初始化,比如申请struct bus_type usb_bus_type,然后会扫描USB总线,看线上连接了哪些USB设备,或者说Root Hub上连了哪些USB设备,比如说连了一个USB键盘,那么就为它准备一个struct device,根据它的实际情况,为这个struct device赋值,并插入devices链表中来。
又比如Root Hub上连了一个普通的Hub,那么除了要为这个Hub本身准备一个struct device以外,还得继续扫描看这个Hub上是否又连了别的设备,有的话继续重复之前的事情,这样一直进行下去,直到完成整个扫描,最终就把 usb_bus_type中的devices链表给建立了起来。
那么drivers链表呢?这个就不用bus方面主动了,而该由每一个driver本身去bus上面登记,或者说挂牌。具体到USB子系统,每一个 USB设备的驱动程序都会对应一个struct usb_driver结构,其中有一个struct device_driver driver成员,USB core为每一个设备驱动准备了一个函数,让它把自己的这个struct device_driver driver插入到usb_bus_type中的drivers链表中去。而这个函数正是我们此前看到的usb_register。而与之对应的 usb_deregister所从事的正是与之相反的工作,把这个结构体从drivers链表中删除。
而struct bus_type结构的match函数在USB子系统里就是usb_device_match函数,它充当了一个红娘的角色,在USB总线的USB设备和 USB驱动之间牵线搭桥,类似于交大BBS上的鹊桥版,虽然它们上面的条件都琳琅满目的,但明显这里match的条件不是那么的苛刻,要更为实际些。
可以说,USB core的确是用心良苦,为每一个USB设备驱动做足了功课,正因为如此,作为一个实际的USB设备驱动,它在初始化阶段所要做的事情就很少,很简单了, 直接调用usb_register即可。事实上,没有人是理所当然应该为你做什么的,但USB core这么做了。所以每一个写USB设备驱动的人应该铭记,USB设备驱动绝不是一个人在工作,在他身后,是USB core所提供的默默无闻又不可或缺的支持。