Binder驱动学习记录

Binder驱动学习

binder_call()

IPC

1. 源
2. 目的: 要发送数据的服务：handle整数表示–>实现该服务的进程
   handle只不过是服务的引用，在不同的进程里面这个handle的值可能不一样
3. 数据

handle

handle是属于某个进程的，handle是进程A对进程B提供服务的s的引用，进程B可能实现了很多个服务，所以这个handle可能指向不同的服务

所以里面肯定有一个成员来描述这个handle
这个成员就是binder_ref

图片1

然后binder_ref中有一个成员binder_node

图片2

binder_node 中还有一个成员binder_pro来描述进程B

图3binder_pro

1.1所以整体驱动中的流程就是（A：client，B：server）

1. 进程A通过handle找到binder_ref，
2. 再通过binder_ref找到binder_node, 驱动中的Binder实体也叫‘节点’，隶属于提供实体的进程，由struct binder_node结构来表示
3. 在binder_node中找到描述进程的结构体binder_proc,
4. -进而找到进程B，获取其中的服务

1.2正常的情况下，会有很多进程A向进程B请求服务，这时进程B就会开启多个线程为多个进程提供服务

那么这样一说，服务进程进程B中肯定有一个结构体来管理这个些线程的结构体struct rb_root thread;因为binder_proc 是描述进程的结构，所以这个rb_root_thread也是binder_proc的成员(如图3)

rb_root_thread 是这个课红黑树的数根，下面会挂有很多线程节点用binder_thread来描述

图2binder_thread

总结：

要先有binder_node，别人才能引用你

1. （内核态）server创建binder_node,为每个服务创建线程，binder_node.proc = server进程
2. (内核态) server_manager 会创建binder_ref 引用binder_node, binder_ref.desc = 1,2,3,
   （用户态）创建一个服务链表，链表含有服务的名字和对应的handle，这个handle就等于 上面的binder_ref.desc
3. client 向server_manager查询服务，传名字给他
4. （内核态）service_manager 返回这个handle给驱动程序（内核态），
5. （内核态）驱动程序在这个server_manager的binder_ref 红黑树中根据handle找到binder_ref,再根据binder_ref，中的binder_node,最后根据给这个client创建新的binder_ref,这个binder_ref指向这个binder_node,它的desc从1开始，群返回desc给client，他就是handle

问题1.client发送数据给这个handle？

1. （内核态）驱动程序根据这个handle找到这个binder_ref,
2. 根据binder_ref找到binder_node,
3. 然后根据binder_node找到进程B，这样就可以传数据给他了

问题2.数据如何传？

client–> server

client端

先写后读

1. 构造数据 调用ioctl发送数据
2. 驱动中 根据handle找到对应server进程
3. 把数据放入进程的某个列表即：数据放入binder_proc 的todo链表中
4. 休眠
5. 被唤醒，从todo链表中取出数据返回用户空间。

对应server端

先读后写

1. 读，数据休眠
2. 当todo链表有数据被唤醒
3. 从todo链表中取出数据返回用户空间
4. 处理数据
5. 将结果写给client，同样它现在作为client一样，将client唤醒

问题3.数据如何复制？

一部方法：（需要两次复制，效率低）

1. client程序构造好数据调用驱动
2. 驱动：copy_form_user

传给server

1. server端：驱动copy_to_user
2. 用户态处理

binder的方法：

1. server程序 mmap（）可以访问，server程序的用户态可以访问驱动中的模块buff
2. client构造数据，驱动copy_from_user直接将数据写到那一块buff
3. 这样server端直接使用数据

所以只用一次拷贝这里说的一次拷贝只是说的是，对于数据本身值复制一次，但是对于封装数据的binder_write_read数据头还是需要复制两次的（client端copy_form_user一次，server端copy_to_user一次）

这里面会涉及一个结构体binder_buffer

---

ioctl分析

应用程序调用驱动提供的ioctl(),完成数据传输

ioctl():

res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);

数据参数：binder_write_read :bws

/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
struct binder_write_read {
 binder_size_t write_size;
 binder_size_t write_consumed;
 binder_uintptr_t write_buffer;
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
 binder_size_t read_size;
 binder_size_t read_consumed;
 binder_uintptr_t read_buffer;
};

那么我们接受方接收到，自然也是一个binder_write_read

在binder_write_read中有一个参数 binder_uintptr_t write_buffer;

write_buffer就是整合的数据

write_buffer 结构体
struct{
    uint32_t cmd;//前面4个字节表示得到的数据类型
    struct binder_transaction_data txn;
}_attribute_(packed) writebuf

接着看一下
binder_transaction_data的结构

struct binder_transaction_data {
     union {
         __u32 handle;
         binder_uintptr_t ptr;
     } target;
    binder_uintptr_t cookie;
    __u32 code;
     __u32 flags;
     pid_t sender_pid;
     uid_t sender_euid;
     binder_size_t data_size;
     binder_size_t offsets_size;
     union {
         struct {
             binder_uintptr_t buffer;
             binder_uintptr_t offsets;
         } ptr;
        __u8 buf[8];
     } data;
};

---

res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
我们来看一下驱动层的ioctl实现

先记录一下调用函数

1. binder_ioctl -BINDER_WRITE_READ:

2. ret = binder_ioctl_write_read(filp, cmd, arg, thread);

3. ret = binder_thread_write(proc, thread,
   bwr.write_buffer,
   bwr.write_size,
   &bwr.write_consumed);

4. binder_transaction

5. binder_alloc_copy_user_to_buffer从用户空间将数据拷贝过来

图1和图2

在驱动内部

我们传递数据时候有相关的操作：

1. BC_TRANSACTION
2. BR_TRANSACTION
3. BC_REPLY
4. BR_REPLY
5. 只有这四个cmd是涉及两个进程间的交互，其他的cmd：例如BC_ENTER_LOOPER/BC_EXIT_LOOPER等都只是app和驱动之间的交互（用于改变或者报告某些状态）。
6. Client端发送消息-BC_TRANSACTION
7. Server端接收消息-BR_TRANSACTION
8. Server端回复消息-BC_REPLY
9. Client端接收消息-BR_REPLY