Android系统--Binder系统具体框架分析（二）Binder驱动情景分析

Android系统--Binder系统具体框架分析（二）Binder驱动情景分析

1. Binder驱动情景分析

1.1 进程间通信三要素

源

目的：handle表示“服务”，即向实现该“服务”的进程发送数据；handle是“服务”的引用

int binder_call(struct binder_state *bs, struct binder_io *msg, struct binder_io *reply,   uint32_t target, uint32_t code)

// bs:驱动信息

// msg:含有服务的名字

// reply:它会含有回复的数据

// target：表示目的

// code：调用的函数

数据

1.2 handle的深入剖析

1.2.1 涉及handle的重要结构体

Binder中的handle：进程A对进程B提供的服务S的引用

引用：通过struct binder_ref结构体关联服务节点

struct binder_ref {//就是 refs_by_desc、refs_by_node 这两个引用树种的数据结构.

int debug_id;

struct rb_node rb_node_desc;//连接des的引用树.

struct rb_node rb_node_node;//连接node的引用树.

struct hlist_node node_entry;

struct binder_proc *proc; //该binder引用所属的进程，

struct binder_node *node;//和远程的binder实体binder_node关联的地方.相对应.

uint32_t desc;

int strong;

int weak;

struct binder_ref_death *death;

};

服务：创建binder_node服务节点，指向进程B

struct binder_node {

int debug_id;

struct binder_work work;

union {

struct rb_node rb_node;

struct hlist_node dead_node;

};

struct binder_proc *proc;

struct hlist_head refs;

int internal_strong_refs;

int local_weak_refs;

int local_strong_refs;

void __user *ptr;

void __user *cookie;

unsigned has_strong_ref : 1;

unsigned pending_strong_ref : 1;

unsigned has_weak_ref : 1;

unsigned pending_weak_ref : 1;

unsigned has_async_transaction : 1;

unsigned accept_fds : 1;

int min_priority : 8;

struct list_head async_todo;

};

进程B：用结构体struct binder_proc表示

struct binder_proc {

struct hlist_node proc_node;//连入总链表的点.

struct rb_root threads; // 红黑树的节点，（不理解红黑树结构，暂时就当成该存储数据的地方即可）

struct rb_root nodes;

struct rb_root refs_by_desc;

struct rb_root refs_by_node;

int pid; //进程的id.

struct vm_area_struct *vma;

struct mm_struct *vma_vm_mm;

struct task_struct *tsk;

struct files_struct *files;

struct hlist_node deferred_work_node;

int deferred_work;

void *buffer;//表示要映射的物理内存在内核空间中的起始位置

//内核使用的虚拟地址与进程使用的虚拟地址之间的差值，即如果某个物理页面在内核空间中对应的虚拟地址是addr的话，

//那么这个物理页面在进程空间对应的虚拟地址就为addr + user_buffer_offset

ptrdiff_t user_buffer_offset;

struct list_head buffers;//通过mmap映射的内存空间.

struct rb_root free_buffers;//空闲的binder_buffer通过成员变量rb_node连入到struct binder_proc中的free_buffers表示的红黑树中去，

struct rb_root allocated_buffers;//正在使用的binder_buffer通过成员变量rb_node连入到struct binder_proc中的allocated_buffers表                                        示的红黑树中去。

size_t free_async_space;

struct page **pages;// struct page 用来描述物理页面的数据结构

size_t buffer_size; //表示要映射的内存的大小.

uint32_t buffer_free;

struct list_head todo;

wait_queue_head_t wait;

struct binder_stats stats;

struct list_head delivered_death;

int max_threads;

int requested_threads;

int requested_threads_started;

int ready_threads;

long default_priority;

struct dentry *debugfs_entry;

};

真实场景中有多个客户端服务对进程B要求服务，进程B创建多个线程提供服务，用struct rb_root结构体（红黑树）管理线程，线程用struct binder_thread描述

struct binder_thread {

struct binder_proc *proc; //当前线程所属的进程。

struct rb_node rb_node; //来连入binder_proc的threads红黑树.

int pid;

int looper;//表示线程的状态  就是上面enum的类型。

struct binder_transaction *transaction_stack; //表示线程正在处理的事务

struct list_head todo; //表示发往该线程的数据列表待处理的一次通信事务.

uint32_t return_error; /* Write failed, return error code in read buf */

uint32_t return_error2; /* Write failed, return error code in read */

/* buffer. Used when sending a reply to a dead process that */

/* we are also waiting on */

wait_queue_head_t wait;  //用来阻塞线程等待某个事件的发生

struct binder_stats stats; //用来保存一些统计信息

};

1.2.2 解析handle对Binder节点操作流程

（1）server传入一个flat_binder_object结构体给驱动，在内核态驱动里为每一个服务创建binder_node,biner_node.proc关联描述进程的结构体

（2）ServiceManager
b1ee
在驱动中创建binder_ref结构体，引用binder_node服务节点

在用户态创建服务链表（name,handle）

binder_ref.desc关联handle

（3）client向ServiceManager传入name查询对应服务

（4）servicemanager返回hanle给驱动程序

（5）驱动程序在servicemanager的binder_ref红黑树中根据handle找到binder_ref结构体，在根据binder_ref.node找到binder_node结构体，最后为client创建新的binder_ref，并关联找到的binder_node节点，他的结构体成员desc从1开始，驱动返回的desc给client,即为handle。

（6）总结client如何得到hanled：驱动根据handle找到binder_ref结构体->binder_node->进程server

1.3 client与server数据传输过程

client端（先读后写）
（1）client构造数据，调用ioctl发送数据

（2）驱动根据handle找到server进程

（3）将数据存入进程的binder_proc.todo

（4）等待唤醒（等待server传回数据）

（5）被唤醒

（6）从todo链表中取出数据，返回用户空间

server端（先写后读）
（1）等待数据传入，休眠

（2）client有数据写入，唤醒

（3）从binder_proc.todo链表当中取出数据，返回用户空间

（4）进行数据处理

（5）将结果写给client，也是放入client中的binder_proc.todo

（6）唤醒client

1.4 数据复制详解

一般方法（需要两次）
（1）client构造数据

（2）client：copy_from_user

（3）server：copy_to_user

（4）用户态处理

Binder方法(一次)
（1）server mmap：用户态可以直接访问驱动中的某块内存

（2）client构造数据：copy_from_user，存放在server mmap映射的内存

（3）server直接获取使用数据

描述一段通过mmap映射的内存空间--结构体binder_buffer来描述

struct binder_buffer {

struct list_head entry; //连入 binder_proc的buffers

//空闲的binder_buffer通过成员变量rb_node连入到binder_proc中的free_buffers表示的红黑树中.

//正在使用的binder_buffer通过成员变量rb_node连入到binder_proc中的allocated_buffers表示的红黑树中去。

struct rb_node rb_node;

unsigned free:1; //每一个binder_buffer又分为正在使用的和空闲的，通过free成员变量来区分.

unsigned allow_user_free:1;

unsigned async_transaction:1;

unsigned debug_id:29;

struct binder_transaction *transaction;

struct binder_node *target_node;

size_t data_size;

size_t offsets_size;

uint8_t data[0];

};

注：一次数据复制是针对传输数据，其binder_write_read还是需要两次复制。client调用ioctl发送数据，ioctl发送的是binder_write_read结构，其结构体中的成员指向传送数据。

1.5 改进binder分析一代码

注册服务，直接将函数作为指针注册

/* add service */

ret = svcmgr_publish(bs, svcmgr, "hello", hello_service_handler);

//注册

if (ret) {

fprintf(stderr, "failed to publish hello service\n");

return -1;

}

ret = svcmgr_publish(bs, svcmgr, "goodbye", goodbye_service_handler);

if (ret) {

fprintf(stderr, "failed to publish goodbye service\n");

}

将被调用函数指向handler，返回handler函数

int test_server_handler(struct binder_state *bs,struct binder_transaction_data *txn,struct binder_io *msg, struct binder_io *reply)

{

int (*handler)(struct binder_state *bs,struct binder_transaction_data *txn,struct binder_io *msg,struct binder_io *reply);  //构造处理方法

handler = (int (*)(struct binder_state *bs,struct binder_transaction_data *txn,struct binder_io *msg,struct binder_io *reply))txn->target.ptr;  //根据txn->target.ptr返回处理相应方法

return handler(bs, txn, msg, reply);  //返回所调用的处理方法

}