Linux设备管理（⼆）_从cdev_add说起
我在⼀⽂中已经简单的介绍了字符设备驱动的基本的编程框架，这⾥我们来探讨⼀下Linux内核(以4.8.5内核为例)是怎么管理字符设备的，即当我们获得了设备号，分配了cdev结构，注册了驱动的操作⽅法集，最后进⾏cdev_add()的时候，究竟是将哪些内容告诉了内核，内核⼜是怎么管理我的cdev结构的，这就是本⽂要讨论的内容。我们知道，Linux 内核对设备的管理是基于kobject的(参见)，这点从我们的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时，会进⾏probe复⽤，此时probe->next就派上了⽤场,⽐如probe[200]，可以表⽰设备号3895等所有对255取余是200的数字, 参见下⽂的kobj_map--58--。
cdev_add
了解了cdev_map的功能，我们就可以⼀探cdev_add()。从中可以看出，其⼯作显然是交给了kobj_map()
cdev_add()
--460-->就是将我们之前获得设备号和设备号长度填充到cdev结构中，
--468-->kobject_get()将kobject的计数减⼀，并返回struct kobject*
//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 }
kobj_map()
这个函数在内核的设备管理中占有重要的地位，这⾥我们只从字符设备的⾓度分析它的功能，这个函数的设计也很单纯，就是封装好⼀个probe结构并将它的地址放⼊probes数组进⽽封装进cdev_map,。
kobj_map()
--48-55-->根据传⼊的设备号的个数，将设备号和cdev依次封装到kmalloc_array()分配的n个probe结构中
--57-63-->就是遍历probs数组，直到到⼀个值为NULL的元素，再将probe的地址存⼊probes, 将设备号对255取余后与probes的下标对应。⾄此，我们就将我们的cdev放⼊的内核的数据结构
//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 }
chrdev_open()
将设备放⼊的内核，我们再来看看内核是怎么到⼀个特定的cdev的。
⾸先，在⼀个字符设备⽂件被创建的时候，内核会构造相应的inode，作为⼀种特殊⽂件，其inode初始化的时候，就会做⼀些准备⼯作
//fs/char_dev.c
429 const struct file_operations def_chr_fops = {
430 .open = chrdev_open,
431 .llseek = noop_llseek,
432 };
//fs/inode.c
1923 void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)
1924 {
1925 inode->i_mode = mode;
1926 if (S_ISCHR(mode)) {
1927 inode->i_fop = &def_chr_fops; //Here
1928 inode->i_rdev = rdev; //and Here
1929 } else if (S_ISBLK(mode)) {
1930 inode->i_fop = &def_blk_fops;
1931 inode->i_rdev = rdev;
1932 } else if (S_ISFIFO(mode))
1933 inode->i_fop = &pipefifo_fops;
1934 else if (S_ISSOCK(mode))
1935 ; /* leave it no_open_fops */
1936 else
1937 printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o) for"
1938 " inode %s:%lu\n", mode, inode->i_sb->s_id,
1939 inode->i_ino);
1940 }
由此可见，对⼀个字符设备的访问流程⼤概是：⽂件路径=>inode=>chrdev_open()=>(kobj_lookup=>)inode.i_cdev=>_chr_open()。所以只要通过VFS到了inode，就可以到chrdev_open()，这⾥我们就来关注⼀个chrdev_open()是怎么从内核的数据结构中到我们的cdev
并执⾏其中的my_chr_open()的。⽐较有意思的是，虽然我们有了字符设备的设备⽂件，inode也被构造并初始化了，但是在第⼀次调⽤chrdev_open()之前，这个inode和具体的chr_dev对象并没有直接关系，⽽只是通过设备号建⽴的"间接"关系。在第⼀次调⽤chrdev_open()之后， inode->i_cdev才被根据设备号到的cdev对象赋值，此后inode才和具体的cdev对象直接联系在了⼀起
//fs/char_dev.c
326 static struct kobject *cdev_get(struct cdev *p)
327 {
328 struct module *owner = p->owner;
329 struct kobject *kobj;
330
331 if (owner && !try_module_get(owner))
332 return NULL;
333 kobj = kobject_get(&p->kobj);
...
336 return kobj;
337 }
351 static int chrdev_open(struct inode *inode, struct file *filp)
352 {
353 const struct file_operations *fops;
354 struct cdev *p;
355 struct cdev *new = NULL;
356 int ret = 0;
...
359 p = inode->i_cdev;
360 if (!p) {
361 struct kobject *kobj;
362 int idx;
...
364 kobj = kobj_lookup(cdev_map, inode->i_rdev, &idx);
...
367 new = container_of(kobj, struct cdev, kobj);
369 /* Check i_cdev again in case somebody beat us to it while
370 we dropped the lock. */
371 p = inode->i_cdev;
372 if (!p) {
373 inode->i_cdev = p = new;
374 list_add(&inode->i_devices, &p->list);
375 new = NULL;
376 } else if (!cdev_get(p))
377 ret = -ENXIO;
378 } else if (!cdev_get(p))
379 ret = -ENXIO;
...
386 fops = fops_get(p->ops);
...
390 replace_fops(filp, fops);
391 if (filp->f_op->open) {linux内核文件放在哪
392 ret = filp->f_op->open(inode, filp);
...
395 }
396
397 return 0;
398
399 out_cdev_put:
400 cdev_put(p);
401 return ret;
402 }
chrdev_open()
--359-->尝试将inode->i_cdev（⼀个cdev结构指针）保存在局部变量p中，
--360-->如果p为空，即inode->i_cdev为空，
--364-->我们就根据inode->i_rdev（设备号）通过kobj_lookup()搜索cdev_map，并返回与之对应kobj，
--367-->由于kobject是cdev的⽗类，我们根据container_of很容易到相应的cdev结构并将其保存在inode->i_cdev中，
--374-->到了cdev，我们就可以将inode->devices挂接到inode->i_cdev的管理链表中，这样下次就不⽤重新搜索，
--378-->直接cdev_get()即可。
--386-->到了我们的cdev结构，我们就可以将其中的操作⽅法集inode->i_cdev->ops传递给filp->f_ops(386-390)，
--392-->这样，我们就可以回调我们的设备打开函数my_chr_open()；如果我们没有实现⾃⼰的open接⼝，就什么都不做，也不是错
扒完了字符设备的注册过程，不知各位看官有没有发现，全程没有⼀个初始化cdev.kobj的函数！到此为⽌，我们都是通过cdev_map来管理系统⾥的字符设备的，所以，我们并不能在sysfs到我们此时注册的字符设备，更深层的原因是内核中并不直接使⽤cdev作为⼀个设备，⽽是将其作为⼀个设备接⼝，使⽤这个接⼝我们可以派⽣出misc设备，输⼊设备，LCD等等，当初始化这些具体的字符设备的时候，相应的list_head对象才可能被打开挂接到相应的链表，并初始化kobj。即如果希望sysfs中到我们的字符设备，我们就必须对cdev.kobj进⾏初始化，挂接到合适的kset，这也就是。
彩蛋
Linux中⼏乎所有的"设备"都是"device"的⼦类，⽆论是平台设备还是i2c设备还是⽹络设备，但唯独字符设备不是，从""⼀⽂中我们可以看出cdev并不是继承⾃device，从""⼀⽂中我们可以看出注册⼀个cdev对象到内核其实只是将它放到cdev_map中，直到""⼀⽂中对device_create的分析才知道此时才创建device结构并将kobj挂接到相应的链表，，所以，基于历史原因，当下cdev更合适的⼀种理解是⼀种接⼝(使⽤mknod时可以当作设备)，⽽不是⽽⼀个具体的设备，和platform_device,i2c_device有着本质的区别
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论