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),
};