usb驱动开发4之总线设备驱动模型

        在上文说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们一起狂欢，但他们有一点是相同的，都只是在等待属于自己的那个另一半。