這里我們來探討一下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"中，打開這個文件，首先注意到就是這個在內核中不常見的靜態(tài)全局變量cdev_map(27)，我們知道，為了提高軟件的內聚性，Linux內核在設計的時候盡量避免使用全局變量作為函數間數據傳遞的方式，而建議多使用形參列表，而這個結構體變量在這個文件中到處被使用，所以它應該是描述了系統(tǒng)中所有字符設備的某種信息，帶著這樣的想法，我們可以在"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封裝了系統(tǒng)中的所有的cdev結構和對應的設備號，最多為255個字符設備。

cdev_add

了解了cdev_map的功能，我們就可以一探cdev_add()

//fs/char_dev.c456 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 }

這個函數的設計也很單純，就是封裝好一個probe結構并將它的地址放入probes數組進而封裝進cdev_map,(48-55)j就是根據傳入的設備號的個數，將設備號和cdev依次封裝到kmalloc_array分配的n個probe結構中，(57-63)就是遍歷probs數組，直到找到一個值為NULL的元素，再將probe的地址存入probes。至此，我們就將我們的cdev放入的內核的數據結構，當然，cdev中大量屬性都是由內核幫我們填充的。

chrdev_open()

將設備放入的內核，我們再來看看內核是怎么找到一個特定的cdev的，對一個字符設備的訪問流程大概是：文件路徑=>inode=>chrdev_open=>cdev->fops->my_chr_open。所以只要通過VFS找到了inode，就可以找到chrdev_open()，這里我們就來關注一個chrdev_open()是怎么從內核的數據結構中找到我們的cdev并回調里滿的my_chr_open()的。首先，chrdev_open()嘗試將inode->i_cdev（一個cdev結構指針）保存在局部變量p中(359)，如果p為空，即inode->i_cdev為空(360)，我們就根據inode->i_rdev（設備號）通過kobj_lookup搜索cdev_map，并返回與之對應kobj(364)，由于kobject是cdev的父類，我們根據container_of很容易找到相應的cdev結構并將其保存在inode->i_cdev中(367)，找到了cdev，我們就可以將inode->devices掛接到inode->i_cdev的管理鏈表中，這樣下次就不用重新搜索，直接cdev_get()即可(378)。找到了我們的cdev結構，我們就可以將其中的操作方法集inode->i_cdev->ops傳遞給filp->f_ops(386-390)，這樣，我們就可以回調我們的設備打開函數my_chr_open()(392);

//fs/char_dev.c326 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 while370 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) {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 }

?