binder数据结构分析

1 binder进程的表述

1.1 ProcessState

binder进程在C++层表述为ProcessState类

class ProcessState : public virtual RefBase { public: static sp<processstate> self(); void setContextObject(const sp<ibinder>& object); sp<ibinder> getContextObject(const sp<ibinder>& caller); void setContextObject(const sp<ibinder>& object, const String16& name); sp<ibinder> getContextObject(const String16& name, const sp<ibinder>& caller); void startThreadPool(); ... sp<ibinder> getStrongProxyForHandle(int32_t handle); ... void spawnPooledThread(bool isMain); ... private: friend class IPCThreadState; ProcessState(); ~ProcessState(); struct handle_entry { IBinder* binder; RefBase::weakref_type* refs; }; handle_entry* lookupHandleLocked(int32_t handle); int mDriverFD; void* mVMStart; mutable Mutex mLock; // protects everything below. Vector<handle_entry>mHandleToObject; ... };

ProcessState类构造函数是私有成员，binder进程只能通过静态成员函数sp<processstate>    self()获取ProcessState类。

sp<processstate> ProcessState::self() { //上锁处理并发情况，函数执行释构函数解锁 Mutex::Autolock _l(gProcessMutex); if (gProcess != NULL) { return gProcess; } //创建ProcessState对象 gProcess = new ProcessState; return gProcess; }

典型的单例设计模式，一个进程只会创建一个ProcessState对象。很容易理解吧，应用程序对应唯一的进程对象，下次再调用静态成员函数sp<processstate>    self()就直接返回ProcessState对象了。

再来看看ProcessState构造函数

ProcessState::ProcessState() : mDriverFD(open_driver()) , mVMStart(MAP_FAILED) , mManagesContexts(false) , mBinderContextCheckFunc(NULL) , mBinderContextUserData(NULL) , mThreadPoolStarted(false) , mThreadPoolSeq(1) { if (mDriverFD >= 0) { mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0); if (mVMStart == MAP_FAILED) { // *sigh* ALOGE("Using /dev/binder failed: unable to mmap transaction memory.\n"); close(mDriverFD); mDriverFD = -1; } } }

open_driver（）打开binder驱动把句柄保存到成员mDriverFD中，mmap映射内核空间地址并把地址保存到成员mVMStart 。

1.2 binder_proc

binder进程在binder驱动中表述为binder_proc结构体，用户空间进程调用open("/dev/binder", O_RDWR)打开驱动的时候，驱动会为该进程在内核空间创建一个binder_proc结构体，并把该结构体链入全局hlist表binder_procs。

struct binder_proc { struct hlist_node proc_node;//通过该节点链入binder驱动全局hlist表binder_procs struct rb_root threads;//用红黑树记录该进程用户空间开启的binder线程，下面再介绍 struct rb_root nodes;//用红黑树记录该进程用户空间的binder实体 struct rb_root refs_by_desc;//用红黑树记录该进程用户空间binder引用，以handle为index struct rb_root refs_by_node;//用红黑树记录该进程用户空间binder引用，以binder实体地址为index 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; //有关binder内存管理，下面再说 ptrdiff_t user_buffer_offset; struct list_head buffers; struct rb_root free_buffers; struct rb_root allocated_buffers; size_t free_async_space; struct page **pages; size_t buffer_size; uint32_t buffer_free; struct list_head todo; //binder_transaction事务储存链表 wait_queue_head_t wait;进程等待队列，当进程以及线程没有事务需要处理(list_empty(&proc->todo)&&list_empty(&thread->todo))，就会在队列上睡眠 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; };

1.2.1 open_driver()

static int open_driver() { //打开驱动 int fd = open("/dev/binder", O_RDWR); if (fd >= 0) { fcntl(fd, F_SETFD, FD_CLOEXEC); int vers = 0; //获取binder驱动版本 status_t result = ioctl(fd, BINDER_VERSION, &vers); if (result == -1) { ALOGE("Binder ioctl to obtain version failed: %s", strerror(errno)); close(fd); fd = -1; } //判断版本 if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) { ALOGE("Binder driver protocol does not match user space protocol!"); close(fd); fd = -1; } //设置该进程支持最大的binder线程数目为15 size_t maxThreads = 15; result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads); if (result == -1) { ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno)); } } else { ALOGW("Opening '/dev/binder' failed: %s\n", strerror(errno)); } return fd; }

open("/dev/binder", O_RDWR)然后调用到binder驱动的binder_open函数

static int binder_open(struct inode *nodp, struct file *filp) { //进程在binder驱动中的表述 struct binder_proc *proc; //分配内存 proc = kzalloc(sizeof(*proc), GFP_KERNEL); //进程内核空间描述符 get_task_struct(current); proc->tsk = current; INIT_LIST_HEAD(&proc->todo); init_waitqueue_head(&proc->wait); //设置进程处理优先级 proc->default_priority = task_nice(current); //涉及到全局变量，上锁处理并发控制 binder_lock(__func__); binder_stats_created(BINDER_STAT_PROC); //把该结构体添加到全局hash链表 hlist_add_head(&proc->proc_node, &binder_procs); //进程id proc->pid = current->group_leader->pid; INIT_LIST_HEAD(&proc->delivered_death); //设置文件描述符私有数据，在其它函数中很容易获得binder_proc结构体 filp->private_data = proc; binder_unlock(__func__); ... return 0; }

每当应用层实例化processstate对象的时候binder驱动都会为构建一个binder_proc 结构体，并把binder_proc 结构体添加到binder驱动全局hlist表中binder_procs。

2 binder线程的表述

2.1 IPCThreadState

binder线程在C++层表述为IPCThreadState类

class IPCThreadState { public: static IPCThreadState* self(); ... private: IPCThreadState(); ~IPCThreadState(); status_t sendReply(const Parcel& reply, uint32_t flags); status_t waitForResponse(Parcel *reply, status_t *acquireResult=NULL); status_t talkWithDriver(bool doReceive=true); status_t writeTransactionData(int32_t cmd, uint32_t binderFlags, int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer); status_t getAndExecuteCommand(); status_t executeCommand(int32_t command); ... static void threadDestructor(void *st); ... const sp<processstate> mProcess; const pid_t mMyThreadId; ... Parcel mIn; Parcel mOut; ... };

像ProcessState类一样。IPCThreadState类构造函数是私有成员，binder线程只能通过静态成员函数static  IPCThreadState*     self();获取其IPCThreadState类。

IPCThreadState* IPCThreadState::self() { if (gHaveTLS) { //默认为false restart: //在该进程中每一个线程第一次以后调用IPCThreadState::self()直接进入这里 const pthread_key_t k = gTLS; //在线程本地存储空间获取IPCThreadState对象 //很明显将会在IPCThreadState实例化的时候把地址放在线程本地存储空间 IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k); //没有则创建 if (st) return st; return new IPCThreadState; } //默认为false if (gShutdown) return NULL; pthread_mutex_lock(&gTLSMutex); //互斥锁 if (!gHaveTLS) { //在该进程中每一个线程第一次调用IPCThreadState::self()将会进入这里 //pthread_key_create作用是创建线程本地存储空间 //也就是同一个进程中，每个线程的gTLS地址空间内容都不相同 //线程退出后会调用threadDestructor函数做一些释放的工作 if (pthread_key_create(&gTLS, threadDestructor) != 0) { pthread_mutex_unlock(&gTLSMutex); return NULL; } gHaveTLS = true; } pthread_mutex_unlock(&gTLSMutex); //无条件跳转指令 goto restart; }

再来看看IPCThreadState构造函数

IPCThreadState::IPCThreadState() : mProcess(ProcessState::self()), //记录对应binder进程对象 mMyThreadId(androidGetTid()), mStrictModePolicy(0), mLastTransactionBinderFlags(0) { pthread_setspecific(gTLS, this); //把IPCThreadState对象记录在线程本地存储空间 //获取线程id clearCaller(); //设置Parcel对象输入输出最大空间 mIn.setDataCapacity(256); mOut.setDataCapacity(256); }

2.2 binder_thread

binder线程在binder驱动表述为binder_thread

struct binder_thread { struct binder_proc *proc; //对应的进程描述 struct rb_node rb_node;//通过该节点链到binder_proc->rb_root threads int pid; //线程id int looper;//线程状态 struct binder_transaction *transaction_stack; //事务栈 struct list_head todo;//binder_transaction事务储存链表 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;//线程等待队列，当线程没有事务需要处理(list_empty(&thread->todo))，就会在队列上睡眠 struct binder_stats stats;// };

2.3 IPCThreadState与binder_thread联系

当进程在用户空间调用ioctl进入binder驱动的时候，都会经过thread = binder_get_thread(proc); 

static struct binder_thread *binder_get_thread(struct binder_proc *proc) { //线程在binder驱动中的表述 struct binder_thread *thread = NULL; //红黑树节点 struct rb_node *parent = NULL; //红黑树节点地址 struct rb_node **p = &proc->threads.rb_node; //遍历proc->threads红黑树，根据线程id为index找出对应线程 while (*p) { parent = *p; //经典的container_of宏定义,由结构体成员地址求结构体地址 thread = rb_entry(parent, struct binder_thread, rb_node); if (current->pid < thread->pid) p = &(*p)->rb_left; else if (current->pid > thread->pid) p = &(*p)->rb_right; else break; } //为线程创建一个binder_thread结构体 if (*p == NULL) { //分配内存 thread = kzalloc(sizeof(*thread), GFP_KERNEL); if (thread == NULL) return NULL; binder_stats_created(BINDER_STAT_THREAD); //记录对应的进程描述binder_proc thread->proc = proc; //记录线程id thread->pid = current->pid; init_waitqueue_head(&thread->wait); INIT_LIST_HEAD(&thread->todo); //以线程id为index插入到proc->threads红黑树 rb_link_node(&thread->rb_node, parent, p); rb_insert_color(&thread->rb_node, &proc->threads); thread->looper |= BINDER_LOOPER_STATE_NEED_RETURN; thread->return_error = BR_OK; thread->return_error2 = BR_OK; } return thread; }

binder_get_thread会根据线程id判断是否已经为用户空间调用ioctl的线程在内核空间创建binder_thread结构体，有则直接返回，没有则创建并插入红黑树中。

3 binder实体、binder引用的表述

在binder初始化篇已经介绍了binder实体在引用层表述为BBinder，而binder引用表述为BpBinder。

3.1 binder_node

binder实体在binder驱动表述为binder_node

struct binder_node { ... struct binder_proc *proc;//所属进程 struct hlist_head refs;//记录所有对该实体的引用 ... void __user *ptr;// void __user *cookie;//BBinder的地址 ... };

在server进程注册了多少个服务，就会在用户空间中实例化多少个BBinder对象，内核空间以BBinder对象在用户空间的地址创建binder_node，并以地址为index链入binder_proc的nodes。

static struct binder_node *binder_new_node(struct binder_proc *proc, void __user *ptr, void __user *cookie) { struct rb_node **p = &proc->nodes.rb_node; struct rb_node *parent = NULL; //Binder实体在驱动中的表述 struct binder_node *node; //以ptr为index，找出新节点binder_node插入的地址 while (*p) { parent = *p; node = rb_entry(parent, struct binder_node, rb_node); if (ptr < node->ptr) p = &(*p)->rb_left; else if (ptr > node->ptr) p = &(*p)->rb_right; else return NULL; } //分配内存 node = kzalloc(sizeof(*node), GFP_KERNEL); if (node == NULL) return NULL; binder_stats_created(BINDER_STAT_NODE); //以ptr为index，把新节点插入到proc->nodes红黑树中 rb_link_node(&node->rb_node, parent, p); rb_insert_color(&node->rb_node, &proc->nodes); node->debug_id = ++binder_last_id; //所属进程 node->proc = proc; node->ptr = ptr; //用户空间BBinder的地址 node->cookie = cookie; node->work.type = BINDER_WORK_NODE; INIT_LIST_HEAD(&node->work.entry); INIT_LIST_HEAD(&node->async_todo); binder_debug(BINDER_DEBUG_INTERNAL_REFS, "binder: %d:%d node %d u%p c%p created\n", proc->pid, current->pid, node->debug_id, node->ptr, node->cookie); return node; }

3.2 binder_ref

binder引用在binder驱动表述为binder_ref

int debug_id; struct rb_node rb_node_desc;//通过该节点链入binder_proc->refs_by_desc红黑树 struct rb_node rb_node_node;//通过该节点链入binder_proc->refs_by_node红黑树 struct hlist_node node_entry;//通过该节点链入binder_node->refs哈希表 struct binder_proc *proc;//所属进程 struct binder_node *node;//对应实体 uint32_t desc;//handle值 int strong;//强引用计数 int weak;//弱引用计数 struct binder_ref_death *death;

client获取服务，实质先在binder驱动根据binder_node信息创建一个binder_ref，然后返回handle值给应用层再创建BpBinder类。

static struct binder_ref *binder_get_ref_for_node(struct binder_proc *proc, struct binder_node *node) { struct rb_node *n; struct rb_node **p = &proc->refs_by_node.rb_node; struct rb_node *parent = NULL; struct binder_ref *ref, *new_ref; while (*p) { parent = *p; ref = rb_entry(parent, struct binder_ref, rb_node_node); if (node < ref->node) p = &(*p)->rb_left; else if (node > ref->node) p = &(*p)->rb_right; else return ref; } new_ref = kzalloc(sizeof(*ref), GFP_KERNEL); if (new_ref == NULL) return NULL; binder_stats_created(BINDER_STAT_REF); new_ref->debug_id = ++binder_last_id; //对应的进程 new_ref->proc = proc; //对应的binder实体 new_ref->node = node; //把binder_ref链入refs_by_node红黑树 rb_link_node(&new_ref->rb_node_node, parent, p); rb_insert_color(&new_ref->rb_node_node, &proc->refs_by_node); new_ref->desc = (node == binder_context_mgr_node) ? 0 : 1; for (n = rb_first(&proc->refs_by_desc); n != NULL; n = rb_next(n)) { ref = rb_entry(n, struct binder_ref, rb_node_desc); if (ref->desc > new_ref->desc) break; new_ref->desc = ref->desc + 1; } p = &proc->refs_by_desc.rb_node; while (*p) { parent = *p; ref = rb_entry(parent, struct binder_ref, rb_node_desc); if (new_ref->desc < ref->desc) p = &(*p)->rb_left; else if (new_ref->desc > ref->desc) p = &(*p)->rb_right; else BUG(); } //把binder_ref链入refs_by_desc红黑树 rb_link_node(&new_ref->rb_node_desc, parent, p); rb_insert_color(&new_ref->rb_node_desc, &proc->refs_by_desc); if (node) { hlist_add_head(&new_ref->node_entry, &node->refs); binder_debug(BINDER_DEBUG_INTERNAL_REFS, "binder: %d new ref %d desc %d for " "node %d\n", proc->pid, new_ref->debug_id, new_ref->desc, node->debug_id); } else { binder_debug(BINDER_DEBUG_INTERNAL_REFS, "binder: %d new ref %d desc %d for " "dead node\n", proc->pid, new_ref->debug_id, new_ref->desc); } return new_ref; }

binder_proc中的refs_by_node和refs_by_desc红黑树作用是一样的，binder_ref都会链入两个红黑树，只是index不一样。

这样binder实体和binder引用就关联上了。

3.3 flat_binder_object

binder实体和引用在各进程间传输，都被封装成flat_binder_object结构体

struct flat_binder_object { /* 8 bytes for large_flat_header. */ unsigned long type; unsigned long flags; /* 8 bytes of data. */ union { void *binder; /* local object */ signed long handle; /* remote object */ }; /* extra data associated with local object */ void *cookie; };

用union表示要么传输的是一个binder实体，要么就是binder引用，能通过type判断出来，若传输的是实体，*binder就是该进程用户空间BBinder的地址，若传输的是引用，handle就是该进程对实体引用的编号。

4 binder内存管理

4.1 映射内存

ProcessState构造函数在内核空间映射了一段内存

mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);

然后会调用binder驱动中的binder_mmap函数。

//用户空间映射的内存信息 static int binder_mmap(struct file *filp, struct vm_area_struct *vma) { int ret; //内核空间映射的内存信息 struct vm_struct *area; //在文件描述符私有数据获取binder_open记录的binder_proc struct binder_proc *proc = filp->private_data; //binder内存管理块 struct binder_buffer *buffer; //最大映射空间为4M if ((vma->vm_end - vma->vm_start) > SZ_4M) vma->vm_end = vma->vm_start + SZ_4M; mutex_lock(&binder_mmap_lock); //以进程的用户空间映射的空间大小来映射内核空间内存 area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP); //映射的内核空间内存首地址 proc->buffer = area->addr; //进程的用户空间虚拟地址与内核空间虚拟地址的相对值 proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffer; mutex_unlock(&binder_mmap_lock); //分配物理页描述指针空间 proc->pages = kzalloc(sizeof(proc->pages[0]) * ((vma->vm_end - vma->vm_start) / PAGE_SIZE), GFP_KERNEL); //分配的内存空间大小 proc->buffer_size = vma->vm_end - vma->vm_start; vma->vm_ops = &binder_vm_ops; vma->vm_private_data = proc; //把用户空间内存地址和内核空间内存地址映射到同一个物理地址 binder_update_page_range(proc, 1, proc->buffer, proc->buffer + PAGE_SIZE, vma); buffer = proc->buffer; INIT_LIST_HEAD(&proc->buffers); //把binder内存管理块(binder_buffer)插入到proc->buffers链表 list_add(&buffer->entry, &proc->buffers); buffer->free = 1; //把空闲的binder内存管理块插入到proc->free_buffers红黑树 binder_insert_free_buffer(proc, buffer); proc->free_async_space = proc->buffer_size / 2; barrier(); proc->files = get_files_struct(proc->tsk); proc->vma = vma; proc->vma_vm_mm = vma->vm_mm; //返回到用户空间 return 0; ... }

再来看看binder_update_page_range函数

static int binder_update_page_range(struct binder_proc *proc, int allocate, void *start, void *end, struct vm_area_struct *vma) { void *page_addr; unsigned long user_page_addr; struct vm_struct tmp_area; //物理页数据结构 struct page **page; struct mm_struct *mm; ... for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) { int ret; struct page **page_array_ptr; //取得proc->pages的第一页 page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE]; BUG_ON(*page); //分配一个物理页 *page = alloc_page(GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO); if (*page == NULL) { printk(KERN_ERR "binder: %d: binder_alloc_buf failed " "for page at %p\n", proc->pid, page_addr); goto err_alloc_page_failed; } tmp_area.addr = page_addr; //映射对应的大小 tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */; page_array_ptr = page; //内核空间虚拟地址映射到一个物理页 ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr); if (ret) { printk(KERN_ERR "binder: %d: binder_alloc_buf failed " "to map page at %p in kernel\n", proc->pid, page_addr); goto err_map_kernel_failed; } //得到用户空间的虚拟地址 user_page_addr = (uintptr_t)page_addr + proc->user_buffer_offset; //用户空间虚拟地址映射到同一个物理页 ret = vm_insert_page(vma, user_page_addr, page[0]); if (ret) { printk(KERN_ERR "binder: %d: binder_alloc_buf failed " "to map page at %lx in userspace\n", proc->pid, user_page_addr); goto err_vm_insert_page_failed; } /* vm_insert_page does not seem to increment the refcount */ } ... }

binder内存管理把用户空间内存地址和内核空间内存地址映射到同一个物理地址，并且只映射一页，后续空间不够才会继续映射其它页。这样分配的用户空间和内核空间地址就能共享同一段物理地址，内核空间传递特定数据给用户空间的时候不需要对这段数据copy_to_user，只要把数据复制到这段内存，并把该段数据在内核空间内存中的地址传递给用户空间，在用户空间访问传递的地址加上proc->user_buffer_offset的值就能访问到这些数据。

4.2 binder_buffer 

驱动为目标进程分配映射的内存都会用binder_buffer结构体来描述这段内存

struct binder_buffer { struct list_head entry; /* free and allocated entries by addesss */ struct rb_node rb_node; /* free entry by size or allocated entry */ /* by address */ unsigned free:1; 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]; };

4.3 分配内存

static struct binder_buffer *binder_alloc_buf(struct binder_proc *proc, size_t data_size, size_t offsets_size, int is_async)

为目标进程分配一段内存，并返回对该段内存描述结构体binder_buffer 。

4.4 释放内存

static void binder_free_buf(struct binder_proc *proc, struct binder_buffer *buffer)

目标进程处理完这些数据后，会及时发BC_FREE_BUFFER命令给驱动释放刚才分配的内存。

5 其它重要结构体

5.1 binder_write_read

struct binder_write_read { signed long write_size; /* bytes to write */ signed long write_consumed; /* bytes consumed by driver */ unsigned long write_buffer; signed long read_size; /* bytes to read */ signed long read_consumed; /* bytes consumed by driver */ unsigned long read_buffer; };

binder用户空间与内核空间交互是用到ioctl(fd, cmd, arg)，其中cmd=BINDER_WRITE_READ命令最为重要，参数是固定的binder_write_read 结构体。数据分为写部分和读部分，如果write_size不等于0就把数据写入binder驱动，并将会调用驱动中的binder_thread_write函数。如果read_size等于0驱动执行完binder_thread_write函数就会返回的应用层，如果read_size不等于0就会阻塞在驱动中的binder_thread_read函数，直到有消息处理才会唤醒，并把读到的数据拷贝到read_buffer的地址中，read_consumed为读到的长度。

5.2 binder_transaction_data

struct binder_transaction_data { /* The first two are only used for bcTRANSACTION and brTRANSACTION, * identifying the target and contents of the transaction. */ //区分进程不同的服务实体或者服务引用 union { size_t handle; /* target descriptor of command transaction */ void *ptr; /* target descriptor of return transaction */ } target; void *cookie; /* target object cookie */ //服务实现类根据服务代理类发来不同的code值调用不同的方法 unsigned int code; /* transaction command */ /* General information about the transaction. */ //flags&TF_ONE_WAY == 1,表示目标进程不需要回复 //flags&TF_ONE_WAY == 0,表示目标进程要回复数据 unsigned int flags; //发送者信息 pid_t sender_pid; uid_t sender_euid; size_t data_size; /* number of bytes of data */ //携带flat_binder_object的个数 size_t offsets_size; /* number of bytes of offsets */ /* If this transaction is inline, the data immediately * follows here; otherwise, it ends with a pointer to * the data buffer. */ union { struct { /* transaction data */ //传输数据的起始地址 const void *buffer; /* offsets from buffer to flat_binder_object structs */ //存放flat_binder_object结构体的地址与buffer偏移值 //只有binder要注册服务、获取服务、传输文件句柄才会携带这个消息 const void *offsets; } ptr; uint8_t buf[8]; } data; };

binder_write_read.write_buffer和binder_write_read.read_buffer也是采用cmd+arg模式。当涉及到两个进程通信，就需要用到binder_transaction_data 结构体，这时候写进程的binder_write_read.write_buffer地址内容就是（cmd = BC_TRANSACTION） + （arg = binder_transaction_data 结构体），binder_transaction_data 其实只是传输数据的消息头，数据有有效负荷还是在binder_transaction_data.data.ptr.buffer地址中，所以内核空间和用户空间中只传递消息头。binder_transaction_data .targe域非常重要，该成员指明发送目的进程。消息发送方是client，目的进程是server，所以binder_transaction_data .targe.handle要填上binder实体的引用号（handle）。当数据到达server进程，仍然是用这个消息头描述接收的数据，server进程在binder_write_read.read_buffer取出消息头。驱动已经把binder_transaction_data .targe.ptr改为binder实体的地址，同时也把cmd修改为BR_TRANSACTION 。server就能通过ptr的值来调用不同的服务。

5.3 binder_transaction

struct binder_transaction { int debug_id; struct binder_work work; struct binder_thread *from; struct binder_transaction *from_parent; struct binder_proc *to_proc; struct binder_thread *to_thread; struct binder_transaction *to_parent; unsigned need_reply:1; /* unsigned is_dead:1; */ /* not used at the moment */ struct binder_buffer *buffer; unsigned int code; unsigned int flags; long priority; long saved_priority; uid_t sender_euid; };

binder_transaction结构体只存在于binder驱动中，发送方在内核空间通过copy_from_user收到用户空间要传递的消息头 binder_transaction_data， 并整理成一个事务binder_transaction，然后通过binder_transaction.work域添加到目标进程或者线程的todo链表，这样目标进程内核空间就会收到这个事务，最终把事务再组织成消息头通过copy_to_user发到用户空间。binder的内存映射目的为了让消息头有效负载的数据不用再次copy_to_user一次，所以发送方内核空间会为目标进程分配一段映射过的内存并记录到这个事务中。何时才会完成这个事务呢？这个事务是记录了收发双方的线程进程相关信息，和内存的分配信息。当然是接收方处理完信息头的有效负载就会发送命令到驱动释放内存，这个事务如果需要回复，就会通过事务记录的信息去回复发送进程，最终在todo链表把这个事务删掉。