浅析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 ;
}