1.Binder系统_驱动情景分析_数据结构

1>. Binder驱动情景分析

起因: 修改了上一个 C 程序实现的 test_client & test_server & service_manager 之后发现, do_add_service 函数里面的 Handle 变量 与 test_client 获得的 Handle 不匹配, 开启了下列分析 :->

1<. 关键结构体

  binder_ref  binder_node  binder_proc  binder_thread  binder_buffer

---

2<. 情节开始

• 1<. binder节点总结:

  • 1<. 起初

    1<. server 在内核态的驱动(binder)程序里面 为每个服务 创建 binder_node.同时将: binder_node.proc = server进程2<. service_manager 在内核态的驱动(binder)程序里面创建 binder_ref 引用 binder_node同时将: binder_ref.desc = <handle : 1, 2, 3>;在用户态会 创建 一个链表

  • 2<. 使用中

    3<. client 向 service_manager 查询服务 : 传入 name4<. service_manager 根据 clien 传入的 name 给驱动程序5<. 驱动(binder)程序在 service_manager 的 binder_ref 里面    采用 红黑树根据 handle 找到 binder_ref    再根据 binder_ref.node 找到 binder_node    最后, 给 client 创建新的 binder_ref, 它的 desc 从 1 开始.    驱动(binder)返回 binder_ref.desc 给 client, 它即为handle

  • 3<. 当 client 发送数据给 handle 时

    驱动(binder)根据 handle 找到 binder_ref,再根据 binder_ref 找到 binder_node再根据 binder_node 找到 server 进程

---

• 2<. 数据传输过程(进程切换)

  • 1<. Client => Server : 先写后读

    1<. Client 构造数据, 调用 ioctl 发送数据2<. 驱动(binder)根据 handle 找到 Server 进程3<. 将 Client 的数据放入 Server进程的 binder_proc.todo 链表里面4<. 休眠 : 等待(Server => Client 的第五步)5<. 被唤醒6<. 从 自己(Client)的 todo 链表里面取出数据, 返回用户空间

  • 2<. Server => Client : 被唤醒后,先读后写

    1<. 读, 唤醒2<. 被唤醒3<. 从 自己(Server)的 todo 链表里面取出数据, 返回用户空间4<. 处理5<. 最后将结果写给 Client 进程的 binder_proc.todo 链表

---

• 3<. 数据如何复制 : 以下过程相关结构体 binder_buffer

  • 1<. 非binder方法: 这里需要拷贝两次

    Client 构造数据 调用ioctl 写驱动(binder): 直接copy_from_user最终传给 Server的时候 读驱动(binder): 直接 copy_to_user, 交给用户态处理

  • 2<. binder方法 :

    首先 用户态的 Server 调用 mmap(), 可以直接访问驱动中的某块内存之后 Client 构造数据 调用ioctl 启动驱动(binder): 直接copy_form_user将数据写入Server mmap的那块内存最终 Server 就可以在用户态直接读取 已存在的 某块内存 就可以了.

    

---

• 4<. 第三点相关结构体定义
  

---

相关补充:

1<. copy_from_user函数 :
目的是从 用户空间 拷贝 数据 到 内核空间

https://baike.baidu.com/item/copy_from_user/18705810?fr=aladdin

2<. copy_to_user 函数 :
目的是从 内核区中 读取 数据到 用户区

https://baike.baidu.com/item/copy_to_user/3049456?fr=aladdin