这段世界大概半个月了,开始linux驱动的真正开发,也是从基层开始看的。相比以为linux下的驱动就是点灯之类的Led来说,现在我的感受就是,那些完全就是表面的东西。核心层次的驱动,完全不是这么随随便便写出来的。也正好说明现在很多公司正在写驱动的不多,完全独立写的也不多,因为实在太复杂。只能靠着源码或者BSP来修改。半个多月来看了linux2.6.10下面的音频驱动OSS架构,不是一般的复杂。熟悉了I2C驱动的整个架构(之前写了一下博文)。
今天为何再写这个内容,因为最近开始看linux下面的视频架构。恍惚间看到device_register和driver_register,这两个对驱动真正核心的东西,让我察觉到这两个到底谁需要先执行,还是没关系。百度了很多,都说的是表面文章,去qq上也是一肚子的灰,因此我依旧独立解决,虽然我知道这个问题基本没人去思考(除了写内核的大神们),因为这块内容和内核走的很近很近,代码量也大。所以基本可见的分析都在表面。故把我这次的分析总结写在这里,供大家借鉴,不对之处也请多指正。
从函数driver_register和device_register在源码中来看,这两个函数的执行顺序前后都有出现,但是之前都活在表面,没有深入的看过,因为知道内核在深入下去就是很复杂的东西。但为了解决问题只会硬着头皮去看。下面是我的一些分析,主要涉及到的是链表,kobject,kset,bus,device,device_driver几个结构体。
1. 先从driver_register的调用流程说起,主要介绍核心的调用,其间的某些函数不做解析。
driver_register->bus_add_driver->
- int bus_add_driver(struct device_driver * drv)
- {
- struct bus_type * bus = get_bus(drv->bus);
- int error = 0;
- if (bus) {
- pr_debug("bus %s: add driver %s\n", bus->name, drv->name);
- error = kobject_set_name(&drv->kobj, "%s", drv->name); //给kobj赋予名字
- if (error) {
- put_bus(bus);
- return error;
- }
- drv->kobj.kset = &bus->drivers; //kset指向bus->drivers(类型为kset)
- if ((error = kobject_register(&drv->kobj))) {
- put_bus(bus);
- return error;
- }
- down_read(&bus->subsys.rwsem);
- driver_attach(drv);
- up_read(&bus->subsys.rwsem);
- module_add_driver(drv->owner, drv);
- driver_add_attrs(bus, drv);
- }
- return error;
- }
在这个函数中,我觉得核心的是语句 drv->kobj.kset = &bus->drivers;,为何会这样说。因为实际上在设备和驱动在注册的过程中,都会将自己结构体的链表成员添加到bus->drivers和bus->devices为链表头的链表中去。最后都根据这些链表遍历所在成员的地址,然后找到设备和驱动依次执行是否probe。
所以 drv->kobj.kset = &bus->drivers;这个做的事情需要结合函数 kobject_register->kobject_add函数中去
- static void unlink(struct kobject * kobj)
- {
- if (kobj->kset) {
- down_write(&kobj->kset->subsys->rwsem);
- list_del_init(&kobj->entry);
- up_write(&kobj->kset->subsys->rwsem);
- }
- kobject_put(kobj);
- }
- /**
- * kobject_add - add an object to the hierarchy.
- * @kobj: object.
- */
- int kobject_add(struct kobject * kobj)
- {
- int error = 0;
- struct kobject * parent;
- if (!(kobj = kobject_get(kobj)))
- return -ENOENT;
- if (!kobj->k_name)
- kobj->k_name = kobj->name;
- parent = kobject_get(kobj->parent);
- pr_debug("kobject %s: registering. parent: %s, set: %s\n",
- kobject_name(kobj), parent ? kobject_name(parent) : "<NULL>",
- kobj->kset ? kobj->kset->kobj.name : "<NULL>" );
- if (kobj->kset) {
- down_write(&kobj->kset->subsys->rwsem);
- if (!parent)
- parent = kobject_get(&kobj->kset->kobj);
- list_add_tail(&kobj->entry,&kobj->kset->list); //kobj的list_head内容加到bus->drivers的list链表中
- up_write(&kobj->kset->subsys->rwsem);
- }
- kobj->parent = parent;
- error = create_dir(kobj);
- if (error) {
- /* unlink does the kobject_put() for us */
- unlink(kobj);
- if (parent)
- kobject_put(parent);
- } else {
- kobject_hotplug(kobj, KOBJ_ADD);
- }
- return error;
- }
在这里有这么一个list_add_tail宏来完成device_driver中将成员kobject的kset链表头加入到kobj->kset->list中去,实际是drv->kobj.kset = &bus->drivers,也就是加入到链表头bus->drivers->list中去。这样就顺利完成了在设备注册时,可以遍历到这个链表头下面的驱动。
总结一下的话,其实devices和driver在注册中,最终都会挂接到bus下面,类型是kset(device和driver)下的list。最终都去遍历这个链表头下面对应的驱动和设备。而我们知道一个驱动可以有多个设备,因此device下的driver_list会添加到driver下面的链表头中去。
相对于driver_register的实现,device_register这方面的实现,就简单多了,一句list_add_tail(&dev->bus_list, &dev->bus->devices.list); //将设备的bus_list加入到devoces.list的链表头中,这个简单了很多很多。很明了,而不需要像驱动那样将kobj下面的链表加入到Bus下面去用于遍历。
总之,这个问题很小,但是和内核走的很近很近,所以,遇到这个问题我想必须解决,这样可以带给我对驱动很深入的理解。继续努力,走在linux的世界里