在上文说usb_init函数,却给我们留下了很多岔路口。这次就来好好聊聊关于总线设备驱动模型。这节只讲理论,不讲其中的函数方法,关于函数方法使用参考其他资料。
总线、设备、驱动对应内核结构体分别为bus_type、device、device_driver。
我们会发现,struct bus_type 结构中有成员struct kset drivers 和struct kset devices,同时struct device结构中有两个成员struct bus_type和structdevice_driver,struct device_driver结构中有两个成员struct bus_type和struct klist。先不说什么是klist、kset,光从成员的名字看,它们就是一个完美的三角关系。
我们知道,struct device中的bus表示这个设备连到哪个总线上,driver表示这个设备的驱动是什么,struct device_driver中的bus表示这个驱动属于哪个总线,klist_devices表示这个驱动都支持哪些设备,因为这里device是复数,又是list,因为一个驱动可以支持多个设备,而一个设备只能绑定一个驱动。
struct bus_type中的drivers和devices分别表示了这个总线拥有哪些设备和哪些驱动。
我们还需要看看什么是klist、kset。还有上面device和driver结构里出现的kobject结构是什么?实际上,kobject和kset都是linux设备模型中最基本的元素,总线、设备、驱动是西瓜,kobjcet、klist是种瓜的人,没有幕后种瓜人的汗水不会有清爽解渴的西瓜,我们不能光知道西瓜的的甜,还要知道种瓜人的辛苦。
kobject和kset存在的意义在于把总线、设备和驱动这样的对象连接到设备模型上。
一般来说应该这么理解,整个linux的设备模型是一个OO的体系结构,总线、设备和驱动都是其中鲜活存在的对象,kobject是它们的基类,所实现的只是一些公共的接口,kset是同种类型kobject对象的集合,也可以说是对象的容器。
只是因为C里不可能会有C++里类的class继承、组合等的概念,只有通过kobject嵌入到对象结构里来实现。这样,内核使用kobject将各个对象连接起来组成了一个分层的结构体系
kobject结构里包含了parent成员,指向了另一个kobject结构,也就是这个分层结构的上一层结点。而kset是通过链表来实现的,这样就可以明白,struct bus_type 结构中的成员drivers 和devices表示了一条总线拥有两条链表,一条是设备链表,一条是驱动链表。
我们知道了总线对应的数据结构,就可以找到这条总线关联了多少设备,又有哪些驱动来支持这类设备。klist其实它就包含了一个链表和一个自旋锁,我们暂且把它看成链表也无妨。
那么总线、设备和驱动它们只见是如何和谐共处?还是先说说总线中的那两条链表是怎么形成的吧。每次出现一个设备就要向总线汇报,或者说注册,每次出现一个驱动,也要向总线汇报,或者说注册。
比如系统初始化的时候,会扫描连接了哪些设备,并为每一个设备建立起一个struct device的变量,每一次有一个驱动程序,就要准备一个struct device_driver结构的变量。把这些变量统统加入相应的链表,device 插入devices 链表,driver插入drivers链表。这样通过总线就能找到每一个设备,每一个驱动。
然而,假如计算机里只有设备却没有对应的驱动,那么设备无法工作。反过来,倘若只有驱动却没有设备,驱动也起不了任何作用。在他们遇见彼此之前,双方都如同路埂的野草,一个飘啊飘,一个摇啊摇,谁也不知道未来在哪里,只能在生命的风里飘摇。于是总线上的两张表里就慢慢的就挂上了那许多孤单的灵魂。devices开始多了,drivers开始多了,他们像是两个来自世界,devices们彼此取暖,drivers们一起狂欢,但他们有一点是相同的,都只是在等待属于自己的那个另一半。