linux的设备模型

(本文节选于电子工业出版社推出的《Linux那些事儿》一书)

这里让我们聚焦Linux的设备模型!

顾名思义,设备模型是关于设备的模型,对咱们写驱动的和不写驱动的人来说,设备的概念就是总 线和与其相连的各种设备了。电脑城的IT工作者都会知道设备是通过总线连到计算机上的,而且还需要对应的驱动才能用,可是总线是如何发现设备的?设备又是 如何和驱动对应起来的?它们经过怎样的艰辛才找到命里注定的那个它?它们的关系如何?白头偕老型的还是朝三暮四型的?这些问题就不是他们关心的了,而是咱 们需要关心的。我们惊喜地发现,这些疑问的中心思想中心词汇就是总线、设备和驱动,没错,它们都是咱们这里要聊的Linux设备模型的“名角”。

总线、设备、驱动,也就是bus、device、driver,既然是“名角”,在内核中都会有它们自己专属的结构,在include/linux/device.h中定义:

  1. struct bus_type {
  2. const char * name;
  3. struct module * owner;
  4. struct kset subsys;
  5. struct kset drivers;
  6. struct kset devices;
  7. struct klist klist_devices;
  8. struct klist klist_drivers;
  9. struct blocking_notifier_head bus_notifier;
  10. struct bus_attribute * bus_attrs;
  11. struct device_attribute * dev_attrs;
  12. struct driver_attribute * drv_attrs;
  13. struct bus_attribute drivers_autoprobe_attr;
  14. struct bus_attribute drivers_probe_attr;
  15. int (*match)(struct device * dev, struct device_driver * drv);
  16. int (*uevent)(struct device *dev, char **envp,
  17. int num_envp, char *buffer, int buffer_size);
  18. int (*probe)(struct device * dev);
  19. int (*remove)(struct device * dev);
  20. void (*shutdown)(struct device * dev);
  21. int (*suspend)(struct device * dev, pm_message_t state);
  22. int (*suspend_late)(struct device * dev, pm_message_t state);
  23. int (*resume_early)(struct device * dev);
  24. int (*resume)(struct device * dev);
  25. unsigned int drivers_autoprobe:1;
  26. };
  27. struct device_driver {
  28. const char * name;
  29. struct bus_type * bus;
  30. struct kobject kobj;
  31. struct klist klist_devices;
  32. struct klist_node knode_bus;
  33. struct module * owner;
  34. const char * mod_name; /* used for built-in modules */
  35. struct module_kobject * mkobj;
  36. int (*probe) (struct device * dev);
  37. int (*remove) (struct device * dev);
  38. void (*shutdown) (struct device * dev);
  39. int (*suspend) (struct device * dev, pm_message_t state);
  40. int (*resume) (struct device * dev);
  41. };
  42. struct device {
  43. struct klist klist_children;
  44. struct klist_node knode_parent; /* node in sibling list */
  45. struct klist_node knode_driver;
  46. struct klist_node knode_bus;
  47. struct device *parent;
  48. struct kobject kobj;
  49. char bus_id[BUS_ID_SIZE]; /* position on parent bus */
  50. struct device_type *type;
  51. unsigned is_registered:1;
  52. unsigned uevent_suppress:1;
  53. struct device_attribute uevent_attr;
  54. struct device_attribute *devt_attr;
  55. struct semaphore sem; /* semaphore to synchronize calls to
  56. * its driver.
  57. */
  58. struct bus_type * bus; /* type of bus device is on */
  59. struct device_driver *driver; /* which driver has allocated this
  60. device */
  61. void *driver_data; /* data private to the driver */
  62. void *platform_data; /* Platform specific data, device
  63. core doesn't touch it */
  64. struct dev_pm_info power;
  65. #ifdef CONFIG_NUMA
  66. int numa_node; /* NUMA node this device is close to */
  67. #endif
  68. u64 *dma_mask; /* dma mask (if dma'able device) */
  69. u64 coherent_dma_mask;/* Like dma_mask, but for
  70. alloc_coherent mappings as
  71. not all hardware supports
  72. 64 bit addresses for consistent
  73. allocations such descriptors. */
  74. struct list_head dma_pools; /* dma pools (if dma'ble) */
  75. struct dma_coherent_mem *dma_mem; /* internal for coherent mem
  76. override */
  77. /* arch specific additions */
  78. struct dev_archdata archdata;
  79. spinlock_t devres_lock;
  80. struct list_head devres_head;
  81. /* class_device migration path */
  82. struct list_head node;
  83. struct class *class;
  84. dev_t devt; /* dev_t, creates the sysfs "dev" */
  85. struct attribute_group **groups; /* optional groups */
  86. void (*release)(struct device * dev);
  87. };

有没有发现它们的共性是什么?对,它们很长,很复杂。不过不妨把它们看成艺术品,既然是艺术品,当然不会让你那么容易就看懂了。

让我们平心静气地看一下上面代码的结构,我们会发现,struct bus_type中有成员struct kset drivers 和struct kset devices,同时struct device中有两个成员struct bus_type * bus和struct device_driver *driver,struct device_driver中有两个成员struct bus_type * bus和struct klist klist_devices。先不说什么是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呢?其实它就包含了一个链表和一个自旋锁,我们暂且把它看成链表也无妨。本来在2.6.11内核中,struct device_driver结构的devices成员就是一个链表类型。

那么总线、设备和驱动之间是如何和谐共处的呢?先说一说总线中的那两条链表是怎么形成的。内 核要求每次出现一个设备就要向总线汇报,或者说注册,每次出现一个驱动,也要向总线汇报,或者说注册。比如系统初始化时,会扫描连接了哪些设备,并为每一 个设备建立起一个struct device的变量,每一次有一个驱动程序,就要准备一个struct device_driver结构的变量。把这些变量统统加入相应的链表,device插入devices 链表,driver插入drivers链表。这样通过总线就能找到每一个设备,每一个驱动。然而,假如计算机里只有设备却没有对应的驱动,那么设备无法工 作。反过来,倘若只有驱动却没有设备,驱动也起不了任何作用。在它们遇见彼此之前,双方都如同路埂里的野草,一个飘啊飘,一个摇啊摇,谁也不知道未来在哪 里,只能在生命的风里飘摇。于是总线上的两张表里就慢慢地就挂上了许多孤单的灵魂。devices开始多了,drivers开始多了,它们像是来自两个不 同的世界,devices们彼此取暖,drivers们一起狂欢,但它们有一点是相同的,都只是在等待属于自己的另一半。

现在,总线上的两条链表已经有了,剩下的那个呢?链表里的设备和驱动又是如何联系的?先有设 备还是先有驱动?很久很久以前,先有的是设备,每一个要用的设备在计算机启动之前就已经插好了,插放在它应该在的位置上,然后计算机启动,操作系统开始初 始化,总线开始扫描设备,每找到一个设备,就为其申请一个struct device结构,并且挂入总线中的devices链表中来。然后每一个驱动程序开始初始化,开始注册其struct device_driver结构,然后去总线的devices链表中去寻找(遍历),去寻找每一个还没有绑定驱动的设备,即struct device中的struct device_driver指针仍为空的设备,然后它会去观察这种设备的特征,看是否是它所支持的设备,如果是,那么调用一个叫做 device_bind_driver的函数,然后它们就结为了“秦晋之好”。换句话说,把struct device中的struct device_driver driver指向这个驱动,而struct device_driver driver把struct device加入它的那张struct klist klist_devices链表中来。就这样,bus、device和driver,这三者之间或者说他们中的两两之间,就给联系上了。知道其中之一,就 能找到另外两个。一荣俱荣,一损俱损。

但现在情况变了,出现了一种新的名词,叫热插拔。此时设备可以在计算机启动以后再插入或者拔 出计算机了。因此,很难再说是先有设备还是先有驱动了,因为都有可能。设备可以在任何时刻出现,而驱动也可以在任何时刻被加载,所以,现在的情况就是,每 当一个struct device诞生,它就会去bus的drivers链表中寻找自己的另一半。反之,每当一个一个struct device_driver诞生,它就去bus的devices链表中寻找它的那些设备。如果找到了合适的,那么和之前那种情况一样,调用 device_bind_driver绑定好。如果找不到,没有关系,就等待吧。

作者: add358   发布时间: 2010-12-05