平台设备驱动详解

本文深入探讨平台设备驱动,阐述平台总线的概念及其管理设备的方式。内容涵盖总线挂载、设备驱动的注册过程,以及总线、设备和驱动之间的探测机制。此外,还详细解析了相关结构体和接口,揭示平台总线设备驱动的全貌。
摘要由CSDN通过智能技术生成

概念:

平台总线只是一种设备模型,其管理的设备本质不变,因此应用访问平台总线上的设备通过/dev这个通道也不会发生改变,只是将设备(符合平台总线设备共性)塞入驱动框架的平台总线来管理,相比字符设备而言只是增加了sys目录下的视图关系。

本章将以平台设备的添加、驱动的注册为切入点,逐步分析总线、平台总线设备的软件层次、组成框架来展示平台总线设备的详情。

应用示例

  1. 平台备添加设:
    static struct platform_device xxx_device = {
        .name = "xxx",
        .id = 0,
        .dev= {
            .platform_data	= xxx_data,
        },
        .num_resources = ARRAY_SIZE(xxx_resources),
        .resource = xxx_resources,
    };
    
    platform_device_register(&smsc_lan9217_device);

总线的挂载

  1. 总线框架
    1. 总线的初始化
      -----itop4412_kernel_3.0/init/main.c-----
      start_kernel
          rest_init();
              kernel_init(void * unused)
                  do_basic_setup();
      ----itop4412_kernel_3.0/drivers/base/init.c-----
                      // /sys下创建class、bus、devices、driver关键子目录、并初始化关键总线
                      driver_init();
                          // 依次生成/sys/devices、/sys/dev、/sys/dev/block、/sys/dev/char子目录及相关父kobj(作后续添加节点的根)
                          buses_init();
                              // 创建一个bus的kset对象,作为后续总线挂载的根节点并生成/sys/bus目录,不再延生,请查看kobject章节
                              bus_kset = kset_create_and_add("bus", &bus_uevent_ops, NULL);
      
      展开:
      struct kset *kset_create_and_add(const char *name,const struct kset_uevent_ops     *uevent_ops,struct kobject *parent_kobj)
          name:所需要创建kset的name
          uevent_ops:uevent操作集
          parent_kobj:父节点对象
                          
    2. 总线的注册:int bus_register(struct bus_type *bus)
      1. 申请一个总线资源对象,并绑定注入的总线包括总线名
      2. 将其根节点置为总线初始化所产生的所有总线根对象bus_kset
      3. 注册该总线至sysfs文件系统,通知用户态在/sys/bus下添加对应的总线目录
      4. 产生该总线下的devices、drivers目录、对应根节点、对应类型链表用于挂载对应这设备
      5. 设置总线的属性
    3. 总结
      1. 驱动框架模型是建立在kobject、sysfs基础之上,因此最终的操作都要归结至此,总线是属于其中的一个分支也需要满足
      2. 所有驱动框架实现需要依赖sysfs文件系统,因此该文件系统应该首先被注册
      3. 总线是虚拟的,并不对应实际的设备,因此总线的初始化并不依赖tmpfs文件系统
  2. 平台总线的注册流程
    -----itop4412_kernel_3.0/init/main.c-----
    start_kernel
        vfs_caches_init(totalram_pages)
            mnt_init();
                // sysfs文件系统先初始化,设备模型需要依赖于sysfs文件系统
                sysfs_init();
        rest_init();
            kernel_init(void * unused)
                do_basic_setup();
                    // tmpfs文件系统先初始化,设备模型不仅在sys下创建视图,同时也会在/dev下创建用户访问通道,因为其本质上还是设备
                    init_tmpfs();
                    // /sys下创建class、bus、devices、driver关键子目录、并初始化关键总线
                    driver_init();
                    // 各模块初始化
                    do_initcalls();
    -----itop4412_kernel_3.0/drivers/base/init.c----
                        driver_init
  • 2
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
将可移动设备连入系统时,系统的后台中会依次发生如下事件: l 内核检测到新硬件插入,然后分别通知hotplug和udev。前者用来装入相应的内核模块(如usb-storage),而后者用来在/dev中创建相应的设备节点(如/dev/sda1)。 l udev创建了相应的设备节点之后,会将这一消息通知hal的守护程序(hald)。当然udev还得保证新创建的设备节点可以被普通用户访问。 l hotplug装入了相应的内核模块之后,会把这一消息通知给hald。 l hald在受到hotplug和udev发出的消息之后,认为新硬件已经正式被系统认可了。此时它会通过一系列精心编写的规则文件(就是传说中的xxx-policy.fdi),把发现新硬件的消息通过dbus发送出去,同时还会调用update-fstab或fstab-sync来更新/etc/fstab,为相应的设备节点创建适合的挂载点。 l 卷管理器会监听dbus中发现新硬件的消息。根据所插入的硬件(区分U盘和数码相机等)不同,卷管理器会先将相应的设备节点挂载到hald创建的挂载点上,然后再打开不同的应用程序。 当然,如果是在CDROM中插入光盘,过程可能比较简单。因为CDROM本身就是一个固定的硬件,无需hotplug和udev的协助: l hald会自己监视CDROM,并且将光盘托架开合的消息通过dbus发出去。 l 卷管理器负责检查CDROM中的盘片内容,进行挂载,并调用合适的应用程序。 要注意,hald的工作是从上游得到硬件就绪的消息,然后将这个消息转发到dbus中。尽管它会调用程序来更新fstab,但实际上它自己并不执行挂载的工作。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值