展讯android LEDS模块分析----各种关系

         言归正传,我想详细说一下这个函数,
bus = bus_get(drv->bus);退回去想一想,drv->bus是什么bus,是&sprd_kb_led_driver->driver->bus,是&platform_bus_type,
priv->driver = drv; drv->p = priv;建立起drv->p 和 drv之间的关系
priv->kobj.kset = bus->p->drivers_kset;   kset 出现了!用来连接上下层之间的关系,其实是把drv绑定到上一层的bus上,
kobject_init_and_add(&priv->kobj, &driver_ktype, NULL,"%s", drv->name)->kobject_add_varg->kobject_set_name_vargs,那么,这个函数就把“keyboard-backlight”这个sprd_kb_led_driver.name对应到sprd_kb_led_driver->p->kobj.name上,然后在通过kobject_add_internal->create_dir就把“keyboard-backlight”创建了个目录挂在了“platform”上。为什么是“platform”上了呢?不是传说中他的上一层目录会是kobject->parent么?如果没记错的话,我们还从未对drv->p->kobject->parent赋过值,那么他应该是NULL才对啊。
        说实话,年轻真好,我记得我高中的时候竟然能够背诵整片的课文,现在回想起来,崇拜自己五体投地。而现在让我想这些链表的对应关系,乱,一团麻!不知道当年写这些东西的大神的脑子是怎么想的。万份怀念谭爷爷!没办法,为生存还得记住他,回头瞅了一眼,的确drv->p->kobject->parent是空,从开天辟地开始。还好那群Linux疯子们没有忘记他,kobject_add_internal中有这么一句判断 parent = kobject_get(kobj->parent);

/* join kset if set, use it as parent if we do not already have one */
if (kobj->kset) {
if (!parent)
parent = kobject_get(&kobj->kset->kobj);
kobj_kset_join(kobj);
kobj->parent = parent;
}
这个时候kset的作用似乎体现了出来一点点。我们曾经对kobject->kset赋过值,您不记得吗?是啊,您依然是皇上,它还是大明湖畔的那个夏雨荷!
priv->kobj.kset = bus->p->drivers_kset;曾经不经意间的一次回眸,换回了今天不用光混。这样,bus->p->drivers_kset->kobject赋给了孤独的drv->p->kobject->parent,so,“platform”目录下面必然有一个叫做“keyboard-backlight”的目录了。

你可能感兴趣的:(JOIN,android,linux,null)