|
浅析linux 2.6.23驱动注册函数driver_register()
文章来源:http://gliethttp.cublog.cn
int driver_register(struct device_driver * drv)
{
if ((drv->bus->probe && drv->probe) ||
//drv和drv所属的bus之中只要1个提供该函数即可,否则也只能调用bus的函数,而不理会drv的
(drv->bus->remove && drv->remove) ||
(drv->bus->shutdown && drv->shutdown)) {
printk(KERN_WARNING "Driver '%s' needs updating - please use bus_type methods\n", drv->name);
}
klist_init(&drv->klist_devices, NULL, NULL);//将drv驱动上的设备链表清空
return bus_add_driver(drv);//将本drv驱动注册登记到drv->bus所在的总线上
}
void klist_init(struct klist * k, void (*get)(struct klist_node *),
void (*put)(struct klist_node *))
{
INIT_LIST_HEAD(&k->k_list);//链表初始化
spin_lock_init(&k->k_lock);//锁初始化
k->get = get;//引用计数操作自定义函数
k->put = put;
}
int bus_add_driver(struct device_driver *drv)
{
struct bus_type * bus = get_bus(drv->bus);
int error = 0;
if (!bus)
return -EINVAL;
pr_debug("bus %s: add driver %s\n", bus->name, drv->name);
//kboj->name[KOBJ_NAME_LEN],如果KOBJ_NAME_LEN长度不够,会调用kmalloc申请
//之后kobj->k_name指针或者指向kboj->name或者指向kmalloc返回地址
error = kobject_set_name(&drv->kobj, "%s", drv->name);
if (error)
goto out_put_bus;
//bus->drivers为kset集合类型,也正是管理本drv->kobj的kset集合
drv->kobj.kset = &bus->drivers;
//gliethttp_20071025 kobject_register()简单理解
//把drv的kobj大张旗鼓的登记到管理它的kset集合上去,同时再根据层级关系创建相应的目录文件
//gliethttp_20071026
//注册登记该kobj,如果该kobj属于某个kset,那么将自己的entry节点挂接到该kset的list链表上,
//以示自己需要该kset的滋润,同时kobj->parent=&kset->kobj,parent指向kset用来管理自己的kobj
//如果该kobj不属于kset,而属于parent,那么简单的将parent的引用计数加1
//对于kobj属于某个kset的情况,可以实现kset向下查找kobj,也可以实现kobj向上查找kset
//对于kobj属于某个parent的情况,查找只能是单向的,只能kobj找到parent,parent不能查找
//该parent挂接的kobj们
//parent是用来明显建立亲子关系图的标志性变量,当然在kset也能若隐若现的显露出这种关系,
//但总不如parent正宗和高效
//之后调用create_dir()创建该kobj在sysfs中的目录文件
//最后调用kobject_uevent()将KOBJ_ADD事件通知到用户空间的守护进程
error = kobject_register(&drv->kobj);
if (error)
goto out_put_bus;
if (drv->bus->drivers_autoprobe) {
//gliethttp_20071025
//driver提供自动匹配函数,那么现在就遍历所有设备
//尝试将本driver匹配到相应设备上去
error = driver_attach(drv);
if (error)
goto out_unregister;
}
//将本driver链接到bus总线上的klist_drivers的klist链表结尾处
klist_add_tail(&drv->knode_bus, &bus->klist_drivers);
module_add_driver(drv->owner, drv);
//gliethttp_20071026
//所以一个驱动需要维持住1个klist链条和一个kobj层次结构--驱动drv->kobj对象,内核一方面使用该kobj在sysfs中建立
//统一的与该kobj对应的目录对象供用户空间访问,另一方面使用该kobj的引用计数来获悉该kobj设备的繁忙与空闲情况,
//当本kobj对象的引用计数到达0时,只要其他条件允许,那么说明集成本kobj的结构体对象不再使用,内核得知这个情况很重要,
//因为这对内核进行进一步的决策提供了详细的证据资料,进而对物理设备进行细致的电源管理成了可能,
//如:当hub1上的所有端口设备都被拔掉之后,hub1就可以安全的进入省电模式了,而这个功能在2.4内核中是找不到的.
//如果从面向对象的角度来看待kset、kobj和driver的话,并不能清晰的说明问题,因为面向对象本身提供的封装、继承和多态
//并不能很好的说明kset、kobj和driver之间存在的实际关系,多少都有一些出入,因为linux毕竟不是用c++写的,不像eCos那样,
//虽然大家都努力借鉴面向对象的光辉思想来设计自己的程序,但是面向对象固有的若干弊端因素也是我们必须要剔除的,
//所以剥丝抽茧之后,呈现出来的东西,大多将处于中间态,当然不排除走极端的少数,所以我觉得使用单纯的面向对象思想来理解
//kset、kobj和driver这3者,最终都会带来理解上的麻烦,因为渗透在他们3者之间的设计思想与封装、继承、多态、类、
//虚函数、属性、方法、类属性和类方法等只是相似,而且"仅仅相似,有些影子,但并不是!"
//因此对于正常理解,最好抛弃单纯的面向对象方式(开始我就使用单纯的面向对象方式来理解,结果在若干单元上卡了壳儿,
//现在想来很是可笑,因为那些单元根本就不是面向对象所具有的,硬是要用面向对象来解决,那完全是在牵强)
//而是采用面向对象和c数据结构相结合的方式,
//而且在结合过程中,为了减少麻烦,最好偏向c数据结构多一点(gliethttp_20071026小感).
//创建属性目录文件
error = driver_add_attrs(bus, drv);
if (error) {
/* How the hell do we get out of this pickle? Give up */
printk(KERN_ERR "%s: driver_add_attrs(%s) failed\n",
__FUNCTION__, drv->name);
}
error = add_bind_files(drv);
if (error) {
/* Ditto */
printk(KERN_ERR "%s: add_bind_files(%s) failed\n",
__FUNCTION__, drv->name);
}
return error;
out_unregister:
kobject_unregister(&drv->kobj);
out_put_bus:
put_bus(bus);
return error;
}
|
