1.內核中每個字符設備都對應一個 cdev 結構的變量，下面是它的定義：
linux-2.6.22/include/linux/cdev.h
struct cdev {
13 struct kobject kobj;
14 struct module *owner;
15 const struct file_operations *ops;
16 struct list_head list;
17 dev_t dev;
18 unsigned int count;
19};
1>kobj是一個嵌入在該結構中的內核對象。它用於該數據結構的一般管理。
2>owner指向提供驅動程序的模塊
3>ops是一組文件操作，實現了與硬件通信的具體操作。
4>dev指定了設備號
5>count表示與該設備關聯的從設備的數目
6>list用來實現一個鏈表，其中包含所有表示該設備的設備特殊文件的inode.
2.一個 cdev 一般它有兩種定義初始化方式：靜態的和動態的
1>靜態內存定義初始化：
struct cdev my_cdev;
cdev_init(&my_cdev, &fops);
my_cdev.owner = THIS_MODULE;
2>動態內存定義初始化：
struct cdev *my_cdev = cdev_alloc();
my_cdev->ops = &fops;
my_cdev->owner = THIS_MODULE;
兩種使用方式的功能是一樣的，只是使用的內存區不一樣，一般視實際的數據結構需求而定。
3. 下面是具體實現
1>struct cdve * cdev_alloc(void)
struct cdev *cdev_alloc(void)
{
struct cdev *p = kzalloc(sizeof(struct cdev), GFP_KERNEL);
if (p) {
INIT_LIST_HEAD(&p->list);
kobject_init(&p->kobj, &ktype_cdev_dynamic);
}
return p;
}
2>void cdev_init(struct cdev *cdev, const struct file_operations *fops)函數
void cdev_init(struct cdev *cdev, const struct file_operations *fops)
{
memset(cdev, 0, sizeof *cdev);
INIT_LIST_HEAD(&cdev->list);
kobject_init(&cdev->kobj, &ktype_cdev_default);
cdev->ops = fops;
}
兩個函數完成都功能基本一致，只是 cdev_init() 還多賦了一個 cdev->ops 的值。
cdev_init的參數fops包含了一些函數指針，指向處理與設備實際通信的函數
4.初始化 cdev 後，需要把它添加到系統中去。為此可以調用 cdev_add() 函數。傳入 cdev 結構的指針，起始設備編號，以及設備編號范圍。
int cdev_add(struct cdev *p, dev_t dev, unsigned count)
{
p->dev = dev;
p->count = count;
return kobj_map(cdev_map, dev, count, NULL, exact_match, exact_lock, p);
}
1>cdev_add的count參數表示該設備提供的從設備號的數量。在cdev_add成功返回後，設備進入活動狀態。
2>kobj_map() 內核中所有都字符設備都會記錄在一個 kobj_map 結構的 cdev_map 變量中。這個結構的變量中包含一個散列表用來快速存取所有的對象。kobj_map() 函數就是用來把字符設備編號和 cdev 結構變量一起保存到 cdev_map 這個散列表裡。當後續要打開一個字符設備文件時，通過調用 kobj_lookup() 函數，根據設備編號就可以找到 cdev 結構變量，從而取出其中的 ops 字段。
5.當一個字符設備驅動不再需要的時候（比如模塊卸載），就可以用 cdev_del() 函數來釋放 cdev 占用的內存
void cdev_del(struct cdev *p)
{
cdev_unmap(p->dev, p->count);
kobject_put(&p->kobj);
}
其中 cdev_unmap() 調用 kobj_unmap() 來釋放 cdev_map 散列表中的對象。kobject_put() 釋放 cdev 結構本身。
本文出自 “驿落黃昏” 博客，請務必保留此出處http://yiluohuanghun.blog.51cto.com/3407300/1082163
