设备模型六(bus, device, driver)

• 前言
  前面讨论已经知道, kset, kobject相当于c++中的基类,会有上层容器去继承他们,c语言里面的继承也就是包含其数据结构的意思,而bus(总线), device(设备),驱动(驱动), 他们三个壮汉继承了他们，从而引出了设备模型的高级部分,这里我们要搞明白以下几点
  1.bus, device, driver的数据结构
  2.三者间的关系
  3.device与driver间的绑定
  开搞！

• 1.bus, device, driver的数据结构

• 1.1感性的认识什么是bus,device, driver
  bus,即总线, 根据<<设备模型一>>文章内容叙述，总线可以是真实总线的抽象,如i2c，也可以是非真实 的总线,为了一致统一， 非真实统一也要跟真实总线一样被抽象，即虚拟总线
  即 i2c(真实总线)—->抽象—>i2c_bus_type
  虚拟总线—>抽象—>platform
  所谓抽象，意思就是说把真实的总线（或虚拟总线）描述成一个数据结构
  对于加入系统中的硬件或者驱动(写代码时会把硬件或者驱动所依赖的总线提前写好), 都会挂靠到总线上
  那什么是挂靠到总线上呢？说白了就是建立三者之间的练习,不如device的数据结构中有一个指针指向bus跟driver，同理driver与bus也是一样的
• 1.2 sysfs上的体现
• 1.2.1在谈sysfs
  sysfs文件系统, 根据前面文章所讲的，体现给用户bus，device，driver的关系层(一目了然)
  大家都知道kset, kobject这些组成上层容器(bus, device, driver)的这些基类,他们的存在就是为了使这三者之间建立联系，并且通过sysfs向用户反映他们之间的联系，打个比方比如我插入Upan，内核检测到U盘插入后会调用device_add来添加设备,这里device_add会调用kobj_add会建立关系,所以你看。。
• 1.2.2 bus的由来
  内核初始化的时候:
  start_kernel–>kernel_init(启动的一个内核线程)–>do_basic_setup–>driver_init
  在driver_init中:

    devices_init();    buses_init();    classes_init();

好的，上面就是这三座大山的初始化, 注意,这里还有个class_init,关于class的讲解，在下一篇文章会讨论
这里简单看一下devices_init()

    devices_kset = kset_create_and_add("devices", &device_uevent_ops, NULL);    if (!devices_kset)        return -ENOMEM;    dev_kobj = kobject_create_and_add("dev", NULL);    if (!dev_kobj)        goto dev_kobj_err;    sysfs_dev_block_kobj = kobject_create_and_add("block", dev_kobj);    if (!sysfs_dev_block_kobj)        goto block_kobj_err;    sysfs_dev_char_kobj = kobject_create_and_add("char", dev_kobj);    if (!sysfs_dev_char_kobj)        goto char_kobj_err;

这里不做过多解释,如果前面的文章都看了的话，相信这里的代码还是比较简单的
对于kset_create_and_add函数的作用前面有讲解:
三个init函数执行完之后,sysfs上的关系如下图所示:

摁，设备模型的骨架子基本上是出来了,之后我们看一下bus的数据结构

• 1.2.3 bus_type
  上面讲到,在linux中真实总线与虚拟总线会被抽象出数据结构,即bus_type,下图会讲述一下bus_type中比较重要的参数
  
  这里说一下bus_type中的match函数,对于每一个总线对应的match函数不同,比较简单的是platform总线
  platform_bus_init–>bus_register(&platform_bus_type);
  其中platform_bus_type

struct bus_type platform_bus_type = {    .name       = "platform",    .dev_attrs  = platform_dev_attrs,    .match      = platform_match, //总线的match函数    .uevent     = platform_uevent,    .pm     = &platform_dev_pm_ops,};

platform_match函数如下

static int platform_match(struct device *dev, struct device_driver *drv){    struct platform_device *pdev = to_platform_device(dev);    struct platform_driver *pdrv = to_platform_driver(drv);    /* Attempt an OF style match first */    if (of_driver_match_device(dev, drv))        return 1;    /* Then try to match against the id table */    if (pdrv->id_table)        return platform_match_id(pdrv->id_table, pdev) != NULL;    /* fall-back to driver name match */    return (strcmp(pdev->name, drv->name) == 0); //这里比较dev与drv的名字是否相等}

上图中,重要的数据结构以及其作用已经很好的表达出来,接下来讨论下注册一个总线时都发生了什么
其实注册一个总线就是形成创建一个上图的关系网

• 1.2.4注册一个总线(虽然现在没有注册总线的机会,但是有必要小研究一下)→bus_register
  我们采用这个方式,从代码中表示生成的步骤,之后用图来描述代码的步骤
  bus_register(&platform_bus_type):

int bus_register(struct bus_type *bus){    int retval;    struct subsys_private *priv;    priv = kzalloc(sizeof(struct subsys_private), GFP_KERNEL); //1.malloc ksubsys_private结构     if (!priv)        return -ENOMEM;    priv->bus = bus; //2.确立关系    bus->p = priv;  //2.与bus确立暧昧关系    BLOCKING_INIT_NOTIFIER_HEAD(&priv->bus_notifier);    retval = kobject_set_name(&priv->subsys.kobj, "%s", bus->name);//3.设置obj名字之后会在sysfs显示，因为sysfs显示的是obj的名字,所以用的bus->name，如上面显示, bus->name为platform    if (retval)        goto out;    priv->subsys.kobj.kset = bus_kset;//4.确立与/sys/bus的关系    priv->subsys.kobj.ktype = &bus_ktype;    priv->drivers_autoprobe = 1;//5.为了加设备后自动添加驱动用    retval = kset_register(&priv->subsys); //6.前面的准备做好后,注册近kobj机制中    if (retval)        goto out;    retval = bus_create_file(bus, &bus_attr_uevent);//7.在/sys/bus/platform生成文件 uevent    if (retval)        goto bus_uevent_fail;    priv->devices_kset = kset_create_and_add("devices", NULL,                         &priv->subsys.kobj); //8.创建devices    if (!priv->devices_kset) {        retval = -ENOMEM;        goto bus_devices_fail;    }    priv->drivers_kset = kset_create_and_add("drivers", NULL,                         &priv->subsys.kobj);//9.创建 drivers    if (!priv->drivers_kset) {        retval = -ENOMEM;        goto bus_drivers_fail;    }    klist_init(&priv->klist_devices, klist_devices_get, klist_devices_put);    klist_init(&priv->klist_drivers, NULL, NULL);    retval = add_probe_files(bus);//10.创建drivers_probe, drivers_autoprobe文件    if (retval)        goto bus_probe_files_fail;    retval = bus_add_attrs(bus);//11.如果bus中还定义了其他的属性文件,则创建    if (retval)        goto bus_attrs_fail;    pr_debug("bus: '%s': registered\n", bus->name);    return 0;bus_attrs_fail:    remove_probe_files(bus);bus_probe_files_fail:    kset_unregister(bus->p->drivers_kset);bus_drivers_fail:    kset_unregister(bus->p->devices_kset);bus_devices_fail:    bus_remove_file(bus, &bus_attr_uevent);bus_uevent_fail:    kset_unregister(&bus->p->subsys);out:    kfree(bus->p);    bus->p = NULL;    return retval;}

10来个步骤,还是比较清晰,下面跟一个图。。。（本人喜欢用图来说明问题,理清思路）

好了，对于bus的注册就讲完了, 下面开讲device_add这个函数,即,往总线添加一个设备都干嘛了,对于加入一个驱动的话同加入设备大同小异了，就不用再细说,老规矩，先分析代码,后根据上面的图进行延伸

• 1.2.5注册设备(device_add)
  当然不同的平台对应不同的device结构,但是里面都会嵌入一个struct device结构
  这里我们以platform_device为例子,给出数据结构,呜哈哈
  
  上图中 dev结构体里面的platform_data是特殊针对,下面我们看一下如何注册一个platform device

static struct platform_device leds_gpio = {    .name   = "xxx_platDev_ma", //定义设备名字    .id = -1, //id初始化    .dev    = {        .platform_data  = NULL,//啥都不说了,dev的一个变量    },};

调用函数platform_device_register(&leds_gpio);
接下来，厉害了！重点介绍一下platform注册都发生了什么，想想都让人兴奋,GO！
当然，不能涉及到所有的细节，我们还是强调脉络的分析

大致的脉络已经体现出来了,至于其他的什么链接文件什么的,个人认为不是什么重点,所以在下面会从现象分析,东西实在太多,接下来我们还是跟据图还说明问题，形象的从图的角度看看都发生了什么，首先,来一个简单的例子

static struct platform_device leds_gpio = {    .name   = "xx_platDev_ma",    .id = -1,    .dev    = {        .platform_data  = NULL    },};struct class *ma_class = NULL;struct device *dev1;struct device *dev2;struct device *dev3;struct device *dev4;static int ma_class_init(void){    int err;    printk(KERN_ALERT "class_init\n");    err = platform_device_register(&leds_gpio); //非常简单,就是注册一个名字为xx_platDev_ma的platform设备    return 0;}static void ma_class_exit(void){    printk(KERN_ALERT "Goodbye, class_init\n");    platform_device_unregister(&leds_gpio);}module_init(ma_class_init);module_exit(ma_class_exit);

我们结合上面的代码逻辑,给出小例子的图解分析

我们将例子insmod后，出现

我们看到/sys下的结构,跟上面分析的一致,摁。。基本上加入一个设备的分析到位了
还差个驱动的绑定,还的继续努力!
1.2.6驱动的绑定,关于这个方面,留个悬念，这里不想说的太多,老生长谈,大家有兴趣可以看下代码,对应的接口函数是bus_probe_device
在上面的1.2.3 中的图已经很清晰的介绍了绑定的流程顺序