浅析linux 2.6.23驱动注册函数driver_register()

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;

}

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/38ArrayArray4/showart_407Array74.html