本文均属自己阅读源码的点滴总结,转账请注明出处谢谢。
欢迎和大家交流。qq:1037701636 email:[email protected],[email protected]
开始我的博文之前,最近一天来的感受,我只想说一下,Linux的世界,玩在表面是轻松的,但是玩在内部那就是找死。佩服那些写源码的人。真的佩服。
这段世界大概半个月了,开始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的世界里