Binder学习一——Binder基础数据结构

在看Binder源码时，总是接触到很多这些莫名其妙的struct，故依据几本参考资料先把这些数据结构的意义即关系整理以下：

/** \kernel\goldfish\drivers\staging\android\binder.c*/

1、binder_work:

//表示binder驱动中进程所要处理的工作项
struct binder_work {
struct list_head entry; //用于实现一个双向链表，存储所有binder_work的队列
enum {
BINDER_WORK_TRANSACTION = 1,
BINDER_WORK_TRANSACTION_COMPLETE,
BINDER_WORK_NODE,
BINDER_WORK_DEAD_BINDER,
BINDER_WORK_DEAD_BINDER_AND_CLEAR,
BINDER_WORK_CLEAR_DEATH_NOTIFICATION,
} type; //描述工作项的类型
};

2、binder_thread:

//存储Binder线程池中的每个线程的信息
struct binder_thread {
struct binder_proc *proc; //宿主进程，即线程属于哪个Binder进程
struct rb_node rb_node; //红黑树中的一个节点，binder_proc使用红黑树来组织Binder线程池中的线程
int pid; //当期线程PID
int looper; //当前线程状态信息
struct binder_transaction *transaction_stack;//事务堆栈，将事务封装成binder_transaction，添加到事务堆栈中，定义了要接收和发送的进程和线程消息
struct list_head todo; //队列，当有来自Client的请求时，将会添加到to_do队列中
uint32_t return_error; //记录处理事务时出现异常错误情况信息
uint32_t return_error2;
wait_queue_head_t wait; /* 等待队列，当Binder处理T1事务依赖于其他Binder线程处理事务T2时， 则会sleep在wait所描述的等待队列中，直至T2事务处理完成再唤醒*/
struct binder_stats stats; //Binder线程相关统计数据
};

//looper状态值
enum {
BINDER_LOOPER_STATE_REGISTERED = 0x01, //Binder驱动请求创建该线程，通过BC_REGISTER_LOOPER协议通知Binder驱动，注册成功设为此状态
BINDER_LOOPER_STATE_ENTERED = 0x02, //该线程是应用程序主动注册的， BC_ENTER_LOOPER
BINDER_LOOPER_STATE_EXITED = 0x04, //Binder线程退出， BC_EXIT_LOOPER
BINDER_LOOPER_STATE_INVALID = 0x08, //异常情况
BINDER_LOOPER_STATE_WAITING = 0x10, //Binder线程处于空闲状态
BINDER_LOOPER_STATE_NEED_RETURN = 0x20 /*表示该线程需要马上返回到用户空间中，使用情形 ： 一：线程注册成为Binder线程后，还没准备好去处理进程间通信，需要返回用户空间做其他初始化等准备 二：进程调用flush来刷新Binder线程池*/
};

3、binder_stats:

//Binder线程相关统计计数
struct binder_stats {
int br[_IOC_NR(BR_FAILED_REPLY) + 1];     // 用于存储BINDER_WRITE_READ读操作命令协议
int bc[_IOC_NR(BC_DEAD_BINDER_DONE) + 1]; // 用于存储BINDER_WRITE_READ写操作命令协议
int obj_created[BINDER_STAT_COUNT];       // 保存对象计数
int obj_deleted[BINDER_STAT_COUNT];
};

4、binder_proc:

/** 描述一个正在使用Binder进程通信的进程，binder_proc为管理其信息的记录体
* 当一个进程open /dev/binder时，Binder驱动程序会为其创建一个binder_proc结构体，用以记录该进程的所有相关信息
* 并把该结构体保存到一个全局的hash表中*/
struct binder_proc {

/** 进程相关参数*/
struct hlist_node proc_node; // 上述全局hash表中的一个节点，用以标记该进程
int pid; // 进程组ID
struct task_struct *tsk; // 任务控制模块
struct files_struct *files; // 文件结构体数组

/** Binder线程池——每一个Binder进程都有一个线程池，由Binder驱动程序来维护
* Binder线程池中所有线程由一个红黑树来组织，RB树以线程ID为关键字；*/
struct rb_root threads; // 上述红黑树根节点

/* 进程可以调用ioctl注册线程到Binder驱动程序中；当线程池中没有足够空闲线程来处理事务时，
* Binder驱动程序可以主动要求进程注册更多的线程到Binder线程池中*/
int max_threads; // Binder驱动程序最多可以请求进程注册的线程的数量
int requested_threads; // Binder驱动程序每主动请求进程添加注册一个线程时，requested_threads加1
int requested_threads_started; // 进程响应Binder要求后，requested_threads_started + 1；requested_threads - 1
// 表示Binder已经主动请求注册的线程数目
int ready_threads; // 进程当前空闲Binder线程数目
long default_priority; // 线程优先级，初始化为进程优先级

/** 一系列Binder实体对象（binder_node）和Binder引用对象(binder_ref)
老罗对此做的概念区分：
1. 在用户空间，运行在Server端的称为Binder本地对象，运行在Client端的称为Binder代理对象。
2. 在内核空间，Binder实体对象用来描述Binder本地对象，Binder引用对象用来描述Binder代理对象。*/
struct rb_root nodes; // Binder实体对象列表（RB树），关键字ptr
struct rb_root refs_by_desc; // Binder引用对象，关键字desc
struct rb_root refs_by_node; // Binder引用对象，关键字node

/** mmap内核缓冲区*/
struct vm_area_struct *vma; // mmap——分配的内核缓冲区 用户空间地址（相较于buffer）
void *buffer; // mmap——分配的内核缓冲区 内核空间地址（相较于vma）(两者都是虚拟地址)
ptrdiff_t user_buffer_offset; // mmap——buffer与vma之间的差值
/** buffer指向的内核缓冲区，被划分成很多小块进行管理；这些小块保存在列表中，buffers就是列表头部*/
struct list_head buffers; // 内核缓冲区列表
struct rb_root free_buffers; // 空闲的内存缓冲区（红黑树）
struct rb_root allocated_buffers; // 正在使用的内存缓冲区（红黑树）
size_t free_async_space; // 当前可用来保存异步事务数据的内核缓冲区大小
struct page **pages; // 对应于vma、buffer虚拟地址，这里是它们对应的物理页面
size_t buffer_size; // 内核缓冲区大小
uint32_t buffer_free; // 空闲内核缓冲区大小

/** 进程每接收到一个通信请求，Binder将其封装成一个工作项，保存在待处理队列to_do中*/
struct list_head todo; // 待处理工作队列
wait_queue_head_t wait; // 等待队列，存放一些睡眠的空闲Binder线程
struct hlist_node deferred_work_node;// hash表，保存进程中可以延迟执行的工作项
int deferred_work; // 延迟工作项的具体类型

struct binder_stats stats; // 统计进程相关数据，具体参见binder_stats结构
struct list_head delivered_death; // 表示Binder驱动程序正在向进程发送的死亡通知
};

5、binder_node:

/** 描述一个Binder实体对象，每一个Service组件在Binder驱动程序中都对应一个Binder实体对象
* Binder驱动程序通过强引用和弱引用计数来维护其生命周期*/
struct binder_node {
int debug_id; // 用以调试
struct binder_work work; //

/** 每一个binder进程都由一个binder_proc来描述
* binder进程内部所有Binder实体对象，由一个红黑树进行组织（struct rb_root nodes）
* rb_node则对应nodes其中的一个节点*/
union {
struct rb_node rb_node; // 用于将本节点连接点红黑树中
struct hlist_node dead_node; /* 如果Binder实体对象对应的进程死亡，销毁节点时需要将rb_node从红黑树中删除，
如果本节点还有引用没有切断，则用dead_node 将其隔离到另一个链表中，
直到通知所有进程切断与该节点的引用后，该节点才能销毁*/
};

/* binder_proc 和 binder_node 关系：
* 可以将binder_proc理解为一个进程，而将binder_node理解为一个Service。
* binder_proc里面有一个红黑树，用来保存所有在它所描述的进程里面创建的Service，
* 而每一个Service在Binder驱动程序里面都用一个binder_node来描述。
* */
struct binder_proc *proc; // 指向该Binder实体对象对应的进程，进程由binder_proc描述
struct hlist_head refs; /* 该Bidner实体对象可能同时被多个Client组件引用，所有指向本实体对象的引用都保存到这个hash队列中
refs表示队列头部；这些引用可能隶属不同进程，遍历该hash表能够得到哪些Client组件引用了该对象*/

/** 引用计数
* 1、当一个Bidner实体对象请求一个Service组件来执行Bidner操作时。会增加该Service组件的强/弱引用计数
* 同时，Binder实体对象会将has_strong_ref与has_weak_ref置为1
* 2、当一个Service组件完成一个Binder实体对象请求的操作后，Binder对象会请求减少该Service组件的强/弱引用计数
* 3、Binder实体对象在请求一个Service组件增加或减少强/弱引用计数的过程中，会将pending_strong_ref和pending_weak_ref置为1
* 当Service组件完成增加或减少计数时，Binder实体对象会将这两个变量置为0*/
int internal_strong_refs; // 强引用计数
int local_weak_refs; // 弱引用计数
int local_strong_refs; // 强引用计数
unsigned has_strong_ref : 1;
unsigned pending_strong_ref : 1;
unsigned has_weak_ref : 1;
unsigned pending_weak_ref : 1;

/** 用来描述用户空间中的一个Service组件*/
void __user *ptr; // 指向该Service组件内部的一个引用计数对象（weakref_impl）的地址？？
void __user *cookie; // 指向该Service组件的地址

/** 异步事务处理，目的在于为同步交互让路，避免长时间阻塞发送端
* 异步事务的定义：（相对于同步事务）单向的进程间通信要求，即不需要等待应答的进程间通信请求
* Binder驱动程序认为异步事务的优先级低于同步事务，则在同一时刻，一个Binder实体对象至多只有一个异步事务会得到处理；而同步事务则无此限制
*
* Binder将事务保存在一个线程binder_thread的todo队列中，表示由该线程来处理该事务
* 每一个事务都关联Binder实体对象（union target），表示该事务的目标处理对象，表示要求该Binder实体对象对应的Serice组件在指定线程中处理该事务
* 而如果Binder发现一个事务是异步事务，则会将其保存在目标Binder实体对象的async_todo的异步事务队列中等待处理*/
unsigned has_async_transaction : 1;// 描述该Binder实体对象是否正在处理一个异步事务，1 表示是
struct list_head async_todo;

/* 表示该Binder实体对象能否接收包含有该文件描述符的进程间通信数据。
* 当一个进程向另一个进程发送数据中包含文件描述符时，Binder会在目标进程中打开一个相同的文件
* 故设为accept_fds为0可以防止源进程在目标进程中打开文件*/
unsigned accept_fds : 1;
int min_priority : 8; // 处理Binder请求的线程的最低优先级
};

6、binder_ref:

/** 用来描述一个Binder引用对象，每一个Client组件在Binder驱动程序中都有一个Binder引用对象,用来描述它在内核中的状态*/
struct binder_ref {
/* Lookups needed: */
/* node + proc => ref (transaction) */
/* desc + proc => ref (transaction, inc/dec ref) */
/* node => refs + procs (proc exit) */
int debug_id; // 用以调试

/** binder_proc中使用红黑树（对应两个rb_root变量）来存储其内部所有的引用对象
* 下面rb_node则是红黑树中的节点*/
struct binder_proc *proc; // Binder引用对象的宿主进程
struct rb_node rb_node_desc; // 对应refs_by_desc，以句柄desc索引
struct rb_node rb_node_node; // 对应refs_by_node，以node索引

/** Client通过Binder访问Service时，仅需指定一个句柄值，Binder通过该desc找到对应binder_ref,再根据该
* binder_ref中的node变量得到binder_node(实体对象)，进而找到对应的Service组件*/
struct hlist_nod enode_entry; // 对应Binder实体对象中（hlist_head）refs引用对象队列中的一个节点
struct binder_node *node; // 引用对象所指向的Binder实体对象
uint32_t desc; // 句柄，用以描述该Binder引用对象

// 强弱引用计数
int strong;
int weak;

/* 表示Service组件接收到死亡通知；*/
struct binder_ref_death *death;
};
7、binder_ref_death:

// 一个死亡通知结构体
/** 易知Client组件无法控制他所引用的Service组件的生命周期，由于Service组件所在进程可能意外崩溃
* Client进程就需要能够在它所引用的Service组件死亡时获得通知，进而进行响应。
* 则Client进程就需要向Binder驱动程注册一个用来接收死亡通知的对象地址(这里的cookie)*/
struct binder_ref_death {
struct binder_work work;// 标志该通知具体的死亡类型
void __user *cookie; // 保存负责接收死亡通知的对象地址
};

/** Binder驱动向Client进程发送死亡通知的情形如下：
* 1、Binder驱动监测到Service组件死亡时，会找到对应Service实体对象（binder_node），再通过refs变量找到引用它的所有Client进程（binder_ref）
* 再通过death变量找到Client进程向Binder注册的死亡通知接收地址；
* Binder将该死亡通知binder_ref_death封装成工作项，添加到Client进程的to_do队列中等待处理。
* 这种情况binder_work类型为BINDER_WORK_DEAD_BINDER
* 2、Client进程向Binder驱动程序注册一个死亡接收通知时
* 如果它所引用的Service组件已经死亡，Binder会立即发送通知给Client进程；
* 这种情况binder_work类型为BINDER_WORK_DEAD_BINDER
*
* 3、当Client进程向Binder驱动程序注销一个死亡通知时，也会发送通知，来响应注销结果
* 1）当Client注销时，Service组件还未死亡：Binder会找到之前Client注册的binder_ref_death，
* 将binder_work修改为BINDER_CLEAR_DEATH_NOTIFICATION,并将通知按上述步骤添加到Client的to_do对列中
* 2）当Client注销时，Service组件已经死亡，Binder同理将binder_work修改为WORK_DEAD_BINDER_AND_CLEAR,然后添加到todo中
* */8、binder_state:

struct binder_state
{
int fd; //打开/dev/binder之后得到的文件描述符
void *mapped; //mmap将设备文件映射到本进程的地址空间中，映射后得到的地址空间地址、及大小
size_t mapsize;
};9、binder_buffer：

/** 内核缓冲区，用以在进程间传递数据
* 回顾binder_proc中的vma与buffers（内核缓冲区列表）*/
struct binder_buffer {
// entry对应内核缓冲区列表buffers中的一个节点
struct list_head entry; /* free and allocated entries by addesss */
/** 结合free,如果free=1，则rb_node对应free_buffers中一个节点（空闲内核缓冲区）
* 如果free！=1,则对应allocated_buffers中一个节点*/
struct rb_node rb_node; /* free entry by size or allocated entry */
unsigned free : 1;

/** Binder将事务数据保存到一个内核缓冲区中（binder_transaction.buffer）,然后交由Binder实体对象（target_node）处理
* 而target_node会将缓冲区的内容交给对应的Service组件（proc）来处理
* Service组件处理完事务后，若allow_user_free=1，则请求Binder释放该内核缓冲区*/
unsigned allow_user_free : 1;
struct binder_transaction *transaction;// 描述一个内核缓冲区正在交给哪个事务transaction，用以中转请求和返回结果
struct binder_node *target_node; // 描述该缓冲区正在被哪个Binder实体对象使用

unsigned async_transaction : 1; // 1表示事务是异步的；异步事务的内核缓冲区大小是受限的，这样可以保证同步事务可以优先得到缓冲区
unsigned debug_id : 29; // 用以调试

/** 存储通信数据，通信数据中有两种类型数据：普通数据与Binder对象，
* 在数据缓冲区最后，有一个偏移数组，记录数据缓冲区中每一个Binder对象在缓冲区中的偏移地址*/
size_t data_size; // 数据缓冲区大小
size_t offsets_size; // 偏移数组的大小（其实也是偏移位置）
uint8_t data[0]; // 用以保存通信数据，数据缓存区，大小可变
};10、binder_transaction:

//描述进程间通信，这个过程称为一个transaction（事务），用以中转请求和返回结果，并保存接收和要发送的进程信息
struct binder_transaction {
int debug_id;
struct binder_work work; // 用来描述待处理的工作项，这里会将其type设置为BINDER_WORK_TRANSACTION,具体结构见binder_work

/** 源线程*/
struct binder_thread *from; // 源线程，即发起事务的线程
long priority; // 源线程的优先级
uid_t sender_euid; // 源线程的用户ID
/** 目标线程*/
struct binder_proc *to_proc; // 目标进程，处理该事务的进程(process)
struct binder_thread *to_thread; // 目标线程：处理该事务的线程

/** 《源代码分析》中的例子：线程A发起事务T1,需要由B线程处理；B处理T1时，需要C先处理T2;C处理T2时，又需要A处理T1；
* 则T1依赖于T2,T2依赖于T3; A 要处理T1，T3，但要先处理T3
* 故： T2->from_parent = T1
* T3->from_parent = T2
* T3->to_parent = T1*/
struct binder_transaction *from_parent; // 表示另一个事务需要依赖该事务(不一定在同一线程中)
struct binder_transaction *to_parent; // 目标线程下一个需要处理的事务

unsigned need_reply : 1; // 标志事务是同步/异步；设为1——表示同步事务，需要等待对方回复；设为0——异步
/*unsigned is_dead : 1;*//* not used at the moment */

/** 参照binder_buffer中解释，指向Binder为该事务分配的内核缓冲区
* code与flags参见binder_transaction_data */
struct binder_buffer *buffer;
unsigned int code;
unsigned int flags;

/** 目标线程处理事务前，Binder需要修改其priority；修改前需要将线程原来的priority保存到saved_priority中，用以处理完事务恢复到原来优先级
* 优先级的设置：目标线程处理事务时，优先级应不低于目标Service组件要求的线程优先级，也不低于源线程的优先级；故设为两者的较大值*/
long saved_priority;
};11、binder_transaction_data：

/* 描述进程间通信所传输的数据：
* Binder对象的传递是通过binder_transaction_data来实现的，
* 即Binder对象实际是封装在binder_transaction_data结构体中。*/
struct binder_transaction_data {

/** 有一个联合体target，当这个BINDER_WRITE_READ命令的目标对象是本地Binder实体时，
就使用ptr来表示这个对象在本进程中的地址，否则就使用handle来表示这个Binder实体的引用。
只有目标对象是Binder实体时，cookie成员变量才有意义，表示一些附加数据;
详细的解释为：传输的数据是一个复用数据联合体，对于BINDER类型，数据就是一个binder本地对象，
如果是HANDLE类型，这数据就是一个远程的handle对象。该如何理解本地binder对象和远程handle对象呢？
其实它们都指向同一个对象，不过是从不同的角度来说。举例来说，假如A有个对象X，对于A来说，
X就是一个本地的binder对象；如果B想访问A的X对象，这对于B来说，X就是一个handle。
因此，从根本上来说handle和binder都指向X。本地对象还可以带有额外的数据，保存在cookie中。 */
union {
size_t handle;/* target descriptor of command transaction */
void *ptr; /* target descriptor of return transaction */
} target;
//Binder实体带有的附加数据
void *cookie; /* target object cookie */
//code是一个命令，描述了请求Binder对象执行的操作,表示要对目标对象请求的命令代码
unsigned int code; /* transaction command */

/* transaction的基本信息*/
//事务标志,见transaction_flags
unsigned int flags;

pid_t sender_pid; // 发起请求的进程PID
uid_t sender_euid; // 发起请求的进程UID

size_t data_size; //data.buffer缓冲区的大小,data见最下面定义；命令的真正要传输的数据就保存在data.buffer缓冲区中
size_t offsets_size; //data.offsets缓冲区的大小

union {
struct {
/* transaction data */
const void *buffer;
/* offsets from buffer to flat_binder_object structs */
const void *offsets;
} ptr;
uint8_t buf[8];
} data;

/** 命令的真正要传输的数据就保存在data.buffer缓冲区中，前面的一成员变量都是一些用来描述数据的特征的。
data.buffer所表示的缓冲区数据分为两类，一类是普通数据，Binder驱动程序不关心，
一类是Binder实体或者Binder引用，这需要Binder驱动程序介入处理。为什么呢？
想想，如果一个进程A传递了一个Binder实体或Binder引用给进程B，那么，
Binder驱动程序就需要介入维护这个Binder实体或者引用的引用计数，防止B进程还在使用这个Binder实体时，
A却销毁这个实体，这样的话，B进程就会crash了。所以在传输数据时，如果数据中含有Binder实体和Binder引和，
就需要告诉Binder驱动程序它们的具体位置，以便Binder驱动程序能够去维护它们。
data.offsets的作用就在这里了，它指定在data.buffer缓冲区中，所有Binder实体或者引用的偏移位置。

注：：
进程间传输的数据被称为Binder对象（Binder Object），
它是一个flat_binder_object。Binder对象的传递是通过binder_transaction_data来实现的，
即Binder对象实际是封装在binder_transaction_data结构体中。*/
};
12、transaction_flags：

/* transaction_flags描述了传输方式，比如同步、异步等*/
enum transaction_flags {
TF_ONE_WAY = 0x01, /* 当前事务异步，不需要等待*/
TF_ROOT_OBJECT = 0x04,/* 包含内容是根对象（暂未使用）*/
TF_STATUS_CODE = 0x08,/* 表示data所描述的数据缓冲区内同是一个4bit状态吗*/
TF_ACCEPT_FDS = 0x10,/* 允许数据中包含文件描述符*/
};13、flat_binder_object：

struct flat_binder_object {
/* 8 bytes for large_flat_header. */
unsigned long type; //Binder对象的类型
unsigned long flags; //Binder对象的标志
/* 8 bytes of data. */
union {
void *binder; /* local object */
signed long handle; /* remote object */
};
/* extra data associated with local object */
void *cookie;
};14、binder_write_read:

/*
* On 64-bit platforms where user code may run in 32-bits the driver must
* translate the buffer (and local binder) addresses apropriately.
*/
/** \kernel\goldfish\drivers\staging\android\binder.h
* 描述进程间通信过程中所传输的数据*/
struct binder_write_read {
/** 输入数据——从用户空间传输到Binder驱动程序的数据，
* 数据协议代码为命令协议代码，由BinderDriverCommandProtocol定义*/
signed long write_size;
signed long write_consumed; // 记录从缓冲区取了多少字节的数据
unsigned long write_buffer; // 指向一个用户空间缓冲区的地址，里面的内容即为输入数据，大小由wirte_size指定

/** 输出数据，从Binder驱动程序，返回给用户空间的数据，
* 数据协议代码为返回协议代码，由BinderDriverReturnProtocol定义*/
signed long read_size;
signed long read_consumed; // 从read_buffer中读取的数据量
unsigned long read_buffer; // 指向用户缓冲区一个地址，里面保存输出数据
};15、BinderDriverCommandProtocol协议：

/** \kernel\goldfish\drivers\staging\android\binder.h
* BC命令协议*/
enum BinderDriverCommandProtocol {
/** 这两个命令数据类型为binder_transaction_data，是最常用到的*/
// 一个Client进程请求目标进程执行某个事务时，会使用BC_TRANSACTION请求Binder驱动程序将通信数据传递到Server目标进程
// 使用者：Client进程 用处：传递数据
BC_TRANSACTION = _IOW('c', 0, struct binder_transaction_data),
// 当Server目标进程处理完事务后，会使用BC_REPLY请求Binder将结果数据返回给Cliet源进程
// 使用者：Server进程， 用处：返回数据
BC_REPLY = _IOW('c', 1, struct binder_transaction_data),

// 当前版本not support
BC_ACQUIRE_RESULT = _IOW('c', 2, int),

/** 数据类型为int，指向Binder内部一块内核缓冲区
* 目标进程处理完源进程事务后，会使用使用BC_FREE_BUFFER来释放缓冲区*/
BC_FREE_BUFFER = _IOW('c', 3, int),

/** 通信数据为int类型，表示binder_ref的句柄值handle
* 前面两个是增加/减少弱引用计数
* 后面两个是增加/减少强引用计数*/
BC_INCREFS = _IOW('c', 4, int),
BC_DECREFS = _IOW('c', 7, int),
BC_ACQUIRE = _IOW('c', 5, int),
BC_RELEASE = _IOW('c', 6, int),

/** Server进程完成增加强/弱引用计数后，会使用这两个命令通知Binder*/
BC_INCREFS_DONE = _IOW('c', 8, struct binder_ptr_cookie),
BC_ACQUIRE_DONE = _IOW('c', 9, struct binder_ptr_cookie),

// 当前不支持
BC_ATTEMPT_ACQUIRE = _IOW('c', 10, struct binder_pri_desc),

/** Binder驱动程序请求进程注册一个线程到它的线程池中，新建立线程会使用BC_REGISTER_LOOPER来通知Binder其准备就绪*/
BC_REGISTER_LOOPER = _IO('c', 11),
/** 一个线程自己注册到Binder驱动程序后，会使用BC_ENTER_LOOPER通知Binder其准备就绪*/
BC_ENTER_LOOPER = _IO('c', 12),
/** 线程发出退出请求，这三条指令都没有通信数据*/
BC_EXIT_LOOPER = _IO('c', 13),

/** 进程向Binder注册一个死亡通知*/
BC_REQUEST_DEATH_NOTIFICATION = _IOW('c', 14, struct binder_ptr_cookie),
/** 进程取消之前注册的死亡通知*/
BC_CLEAR_DEATH_NOTIFICATION = _IOW('c', 15, struct binder_ptr_cookie),

/** 数据指向死亡通知binder_ref_death的地址
* 进程获得Service组件的死亡通知后，会使用该命令通知Binder其已经处理完该死亡通知*/
BC_DEAD_BINDER_DONE = _IOW('c', 16, void *),
};16、binder_ptr_cookie:

/**\binder.h
* 可以用来描述一个Binder实体对象或一个Service组件的死亡通知
* 1、Binder实体对象：ptr，cookie见binder_node
* 2、死亡通知：ptr指向一个Binder引用对象的句柄值
* cookie指向接收死亡通知的对象的地址*/
struct binder_ptr_cookie {
void *ptr;
void *cookie;
};17、BinderDriverReturnProtocol:

enum BinderDriverReturnProtocol {
/** Binder驱动程序处理进程发送的请求时，发生异常，在返回BR_ERROR通知该进程
* 数据类型为int，表示错误代码*/
BR_ERROR = _IOR('r', 0, int),

/** 表示通知进程成功处理了该事务*/
BR_OK = _IO('r', 1),

/** 对应前面的BC；
* 1、 Client进程向Server进程发送通信请求（BC），Binder使用BR_TRANSACTION通知Server
* 使用者：Binder驱动程序 用途：通知Server
* 2、erver处理完请求使用BC通知Binder，Binder使用BR_REPLY通知Client
* 使用者：Binder驱动程序用途：通知Client*/
BR_TRANSACTION = _IOR('r', 2, struct binder_transaction_data),
BR_REPLY = _IOR('r', 3, struct binder_transaction_data),

// 当前不支持
BR_ACQUIRE_RESULT = _IOR('r', 4, int),

// Binder处理请求时，发现目标进程或目标线程已死亡，通知源进程
BR_DEAD_REPLY = _IO('r', 5),

// Binder接收到BC_TRANSACTION或BC_REPLY时，会返回BR_TRANSACTION_COMPLETE通知源进程命令已接收
BR_TRANSACTION_COMPLETE = _IO('r', 6),

// 增加减少强弱引用计数
BR_INCREFS = _IOR('r', 7, struct binder_ptr_cookie),
BR_ACQUIRE = _IOR('r', 8, struct binder_ptr_cookie),
BR_RELEASE = _IOR('r', 9, struct binder_ptr_cookie),
BR_DECREFS = _IOR('r', 10, struct binder_ptr_cookie),

// 当前不支持
BR_ATTEMPT_ACQUIRE = _IOR('r', 11, struct binder_pri_ptr_cookie),

// Binder通知源进程执行了一个空操作；用以可以替换为BR_SPAWN_LOOPER
BR_NOOP = _IO('r', 12),

// Binder发现没有足够的线程处理请求时，会返回BR_SPAWN_LOOPER请求增加新的线程到Binder线程池中
BR_SPAWN_LOOPER = _IO('r', 13),

// 当前不支持
BR_FINISHED = _IO('r', 14),

/** void*指针指向用来接收Service组件死亡通知的对象的地址
* Binder监测到Service组件死亡时，使用BR_DEAD_BINDER通知Client进程
* Client请求注销之前的死亡通知，Binder完成后，返回BR_CLEAR_DEATH_NOTIFICATION_DONE*/
BR_DEAD_BINDER = _IOR('r', 15, void *),
BR_CLEAR_DEATH_NOTIFICATION_DONE = _IOR('r', 16, void *),

// 发生异常，通知源进程
BR_FAILED_REPLY = _IO('r', 17),
};