Linux设备管理(二)

我在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_map封装了系统中的所有的cdev结构和对应的设备号,最多为255个字符设备

Linux设备管理(二)

cdev_add

了解了cdev_map的功能,我们就可以一探cdev_add()

//fs/char_dev.c 456 int cdev_add(struct cdev *p, dev_t dev, unsigned count) 457 { 458 int error; 459 460 p->dev = dev; 461 p->count = count; 462 463 error = kobj_map(cdev_map, dev, count, NULL, 464 exact_match, exact_lock, p); 465 if (error) 466 return error; 467 468 kobject_get(p->kobj.parent); 469 470 return 0; 471 }

函数很短,(460-461)就是将我们之前获得设备号和设备号长度填充到cdev结构中,kobject_get()(468)也没做什么事:

//lib/kobject.c 591 struct kobject *kobject_get(struct kobject *kobj) 592 { 593 if (kobj) { ... 598 kref_get(&kobj->kref); 599 } 600 return kobj; 601 }

所以,核心工作显然是交给了kobj_map()

kobj_map()

这个函数在内核的设备管理中占有重要的地位,这里我们只从字符设备的角度分析它的功能,先上实现

//drivers/base/map.c 32 int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range, 33 struct module *module, kobj_probe_t *probe, 34 int (*lock)(dev_t, void *), void *data) 35 { 36 unsigned n = MAJOR(dev + range - 1) - MAJOR(dev) + 1; 37 unsigned index = MAJOR(dev); 38 unsigned i; 39 struct probe *p; ... 44 p = kmalloc_array(n, sizeof(struct probe), GFP_KERNEL); ... 48 for (i = 0; i < n; i++, p++) { 49 p->owner = module; 50 p->get = probe; 51 p->lock = lock; 52 p->dev = dev; 53 p->range = range; 54 p->data = data; 55 } 56 mutex_lock(domain->lock); 57 for (i = 0, p -= n; i < n; i++, p++, index++) { 58 struct probe **s = &domain->probes[index % 255]; 59 while (*s && (*s)->range < range) 60 s = &(*s)->next; 61 p->next = *s; 62 *s = p; 63 } 64 mutex_unlock(domain->lock); 65 return 0; 66 }

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/359a9cdc546c0dd7c8d63bfbecedd76d.html