cdev linux_Linux设备管理（二）_从cdev_add说起

我在Linux字符设备驱动框架一文中已经简单的介绍了字符设备驱动的基本的编程框架，这里我们来探讨一下Linux内核(以4.8.5内核为例)是怎么管理字符设备的，即当我们获得了设备号，分配了cdev结构，注册了驱动的操作方法集，最后进行cdev_add()的时候，究竟是将哪些内容告诉了内核，内核又是怎么管理我的cdev结构的，这就是本文要讨论的内容。我们知道，Linux内核对设备的管理是基于kobject的(参见Linux设备管理(一)_kobject_kset_kobj_type)，这点从我们的cdev结构中就可以看出，所以，接下来，你将看到"fs/char_dev.c"中实现的操作字符设备的函数都是基于"lib/kobject.c"以及"drivers/base/map.c"中对kobject操作的函数。好，现在我们从cdev_add()开始一层层的扒。

cdev_map对象

//fs/char_dev.c

27 static struct kobj_map *cdev_map;

内核中关于字符设备的操作函数的实现放在"fs/char_dev.c"中，打开这个文件，首先注意到就是这个在内核中不常见的静态全局变量cdev_map(27)，我们知道，为了提高软件的内聚性，Linux内核在设计的时候尽量避免使用全局变量作为函数间数据传递的方式，而建议多使用形参列表，而这个结构体变量在这个文件中到处被使用，所以它应该是描述了系统中所有字符设备的某种信息，带着这样的想法，我们可以在"drivers/base/map.c"中找到kobj_map结构的定义:

//drivers/base/map.c

19 struct kobj_map {

20 struct probe {

21 struct probe *next;

22 dev_t dev;

23 unsigned long range;

24 struct module *owner;

25 kobj_probe_t *get;

26 int (*lock)(dev_t, void *);

27 void *data;

28 } *probes[255];

29 struct mutex *lock;

30 };

从中可以看出，kobj_map的核心就是一个struct probe类型、大小为255的数组，而在这个probe结构中，第一个成员next(21)显然是将这些probe结构通过链表的形式连接起来，dev_t类型的成员dev显然是设备号，get(25)和lock(26)分别是两个函数接口，最后的重点来了，void作为C语言中的万金油类型，在这里就是我们cdev结构(通过后面的分析可以看出)，所以，这个cdev_map是一个struct kobj_map类型的指针，其中包含着一个struct probe*类型、大小为255的数组，数组的每个元素指向的一个probe结构封装了一个设备号和相应的设备对象(这里就是cdev)，下图中体现两种常见的对设备号和cdev管理的方式,其一是一个cdev对象对应这一个/多个设备号的情况, 在cdev_map中, 一个probes对象就对应一个主设备号，多个设备号对应一个cdev时，其实只是次设备号在变，主设备号还是一样的，所以是同一个probes对象；其二是当主设备号超过255时,会进