Linux内核大讲堂 (二) 传说中的字符设备(1)
Linux内核大讲堂 (二) 传说中的字符设备(1)
就当我还在学校的时候，我就曾在一个装机群里听一位装机圣手说，驱动程序的安装没你想的那么简单，分类型的，分为字符设备驱动和块设备驱动。我当时就纳闷了，我说我装机的时候好像没看到啊，我就把光盘放过去然后就一直点下一步，然后重启就好了啊。后面我在群里被几位高手围攻，败下阵来，时过境迁，哥现在也算是道上混的兄弟了，再也没那么容易被蒙了。就算你DIY再牛，你也不要和我说装驱动要分类。否则我就和你讲内核，讲晕你再说。看谁更能吹，哈哈。我得意的笑。我发现学内核的一个好处，就是非常好装B。你只要把内核里面的名词背熟了，拿出来去吓唬吓唬人，挺管用的，不过撞到行家的话，你就要注意了。呵呵。
好了，学内核不是为了吓唬人的，是为了掌握其原理，学习其技巧与方法，知其然而知其所以然，另外内核代码是具有一定复杂度的，看了内核代码再看看我们自已写的，和玩具没啥两样，这就是学内核的好处！
如果看了驱动模型系列文章的朋友应该有这种感受：你这玩意折腾来折腾去半天的，昨不干活呢？
我本来是打算把要讲的东西全部都自已实现一套，如果把这整个一系列看完的话，应该是具备了自已制作总线，驱动，设备，文件系统等一系列能力的，但是这样下去的话，一者怕大家受不了，二者说实话，我也不好受，需要花费的时间精力过大。是重复造轮子。并且造的还不如人家的好。所以就决定还是回归本原，不到万不得已，不打算自已写了！
字符设备是传说中的东西，玩过linux的人都知道这个东西，很多同志也可以照猫画虎的写出一个字符设备。但哥不，哥是有追求的人，知其然，必需得知其所以然。我决不会不负责任的把大家领进门后就不管了。我依然会不惜笔墨的把该说的全都说清楚。我们先不用去抠概念，不要说，什么是字符设备啊，什么是块设备啊。这些都没意义，你最需要知道的是这个叫字符设备的东西究竟都干了些啥？他到底是怎么工作的？搞清楚后，什么是字符设备你就明白了。如果再学块设备，一对比，差异在哪？你就明白了。我学习一向都不喜欢抠概念。有的同志你叫字符设备他回答你说char设备，你说块设备他说block设备，你说底半部他说下半部。你说NXP他说恩智浦，还好哥是道上混的，多少知道一点。否则就被人家给唬住了。好了，闲话不多说了，总的来说要表达的就是一种学习态度：不用抠概念。
接下来我们欣赏一下字符设备。
看过驱动模型系列文章的同志现在应该有一种意识了，我们暂且把它叫做“初始化意识”。就是说你用register_chrdev()注册的时候是很爽，但是那是因为前人把路铺好了，好，我们就来看看前人都做了些啥，再提醒一次一定要有“初始化意识”。
我们在“初始化意识”的指引下找到了一个文件:char_dev.c。打开这个文件一看。有这么一个初始化函数：
void __init chrdev_init(void)
{
cdev_map = kobj_map_init(base_probe, &chrdevs_lock);
bdi_init(&directly_mappable_cdev_bdi);
}
base_probe是一个很简单的函数：
static struct kobject *base_probe(dev_t dev, int *part, void *data)
{
if (request_module("char-major-%d-%d", MAJOR(dev), MINOR(dev)) > 0)
/* Make old-style 2.4 aliases work */
request_module("char-major-%d", MAJOR(dev));
return NULL;
}
request_module这个函数先大概知道意思就行了，他的意思是请求加载一个模块。
chrdevs_lock是一把大大的锁。没别的，就这两玩意。
关键在：
struct kobj_map *kobj_map_init(kobj_probe_t *base_probe, struct mutex *lock)
{
struct kobj_map *p = kmalloc(sizeof(struct kobj_map), GFP_KERNEL);
struct probe *base = kzalloc(sizeof(*base), GFP_KERNEL);
int i;
if ((p == NULL) || (base == NULL)) {
kfree(p);
kfree(base);
return NULL;
}
base->dev = 1;
base->range = ~0;
base->get = base_probe;
for (i = 0; i < 255; i++)
p->probes[i] = base;
p->lock = lock;
return p;
}
最关键的一个角色就在这种神不知鬼不觉的情况下登场了，那就是struct kobj_map。
我们可以看到首先用kmalloc分配了一块内存并赋值给struct kobj_map *p了。
struct kobj_map {
struct probe {
struct probe *next;
dev_t dev;
unsigned long range;
struct module *owner;
kobj_probe_t *get;
int (*lock)(dev_t, void *);
void *data;
} *probes[255];
struct mutex *lock;
};
里面内嵌了一个长度为255的结构体数组和一把锁。
Linux内核里面如果是直接分配比较大块的内存，基本都是有hash思想在里面的，主要是为了效率。这个结构体中的成员等会大家就知道干嘛用的了。
接下来
struct probe *base = kzalloc(sizeof(*base), GFP_KERNEL);
内核作者你就卖弄吧。写成struct probe *base = kzalloc(sizeof(struct probe), GFP_KERNEL)这样多好？不管了，随便了，反正我只取其精华。
接下来：
if ((p == NULL) || (base == NULL)) {
kfree(p);
kfree(base);
return NULL;
}
如果对这个有疑问的同志可以仔细研究一下kfree函数。这个是没有问题的。我再说一个思想，有疑问就看源码，不要去翻书，或者google百度的。Linux内核里面的函数全都是自给自足的，你所有的疑问都可以通过翻阅内核源码本身得到解决。当然啦，如果不是说不要去看书，我的意思是能不看就尽量不看。
接下来：
base->dev = 1;
base->range = ~0; //取反，比你写一堆0xff...好多了，并且可移植性更好
base->get = base_probe;//把函数指针指向传进来的那个回调函数。
接下来：
for (i = 0; i < 255; i++)
p->probes[i] = base;
用base初始化整个kobj_map.probe[255]。
p->lock = lock;
return p;
最后把锁也传过来，并返回指针。
接下来：
bdi_init(&directly_mappable_cdev_bdi);
这个玩意先不用管了，这个对我们理解字符设备目前没有任何帮助，并且只能添乱。
好了。今天就到这吧。
下一节可能会比较久，最近实在太忙了。请各位体谅一下！谢谢。 抽烟去罗。^_^
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/z2007b/archive/2011/05/25/6445841.aspx