binder驱动使用的数据结构说明

一、Binder的ioctl接收的指令，以及数据接收格式：
1、BINDER_WRITE_READ
最常用的数据命令。
接收的数据格式是struct binder_write_read的指针，这个结构体可以用的很灵活。下边根据不同的方法继续分析。
2、BINDER_SET_MAX_THREADS
参数直接就是ioctl里的参数：arg指定的数据。
3、BINDER_SET_CONTEXT_MGR
不需要参数。
4、BINDER_THREAD_EXIT
不需要参数。
5、BINDER_VERSION
不需要参数。

二、binder_thread_write：
这个方法接收的是struct binder_write_read指针指向的write_buffer，以及write_size。

write_buffer的前32位一定是命令，命令后面的内容就需要根据不同的命令来分辨了。命令包括：
1、BC_INCREFS,BC_ACQUIRE,BC_RELEASE,BC_DECREFS：
这几个命令后面接着的是一个32位的target，表示的意义是binder内部的ref的编号。
2、BC_INCREFS_DONE,BC_ACQUIRE_DONE：
跟着的是一个占了 sizeof(void*)大小的指针值，再后面是一个占了sizeof(void *)大小的cookie
3、BC_FREE_BUFFER：
命令后跟的是一个data_ptr。
4、BC_TRANSACTION,BC_REPLY：
关键的一个地方，命令后跟的是一个struct binder_transaction_data结构的内容。
5、BC_REGISTER_LOOPER：
后面再补。
…

三、binder_transaction：
这个方法接收的是struct binder_transaction_data指针。这个结构体挺复杂。
重点解析一下里面的几个字段：
data_size：表示数据缓冲区的大小
offsets_size：表示offset区域的有效offset的大小
data.ptr.buffer：表示指向数据缓存区的起始位置
data.ptr.offsets：表示指向offset区域的起始位置。
对于整个数据缓存区来说，前半部分是offset区域，后半部分是data区域。Offset区域的每4个字节表示了一个偏移值，这个偏移值是相对于data起始位置的偏移值。当在data区域嵌入一个flat_binder_object时，就会在data区域写入该obj的内容，然后再offset区域记录写入位置相对于data起始位置的偏移值。

我们结合另一个可以比较准备的反应这个关系的数据结构：struct binder_io来分析：
一开始的时候，分配了一个某大小的总区域，然后，根据最多需要多少个offset，每个offset占4个字节，定出数据区域的起始位置data0。而offs0则指向offset区域的的起始位置，同时也是指向这个整个区域的起始位置。Data指针一开始与data0相同，offs指针一开始与offs0相同。
当向data区域写入数据时，data指针会增长，如果是写入obj（一定是flat_binder_object结构的对象），则会在offset区域增加一项纪录，同时offset指针向后移动4个字节。
offs_avail就是offset区域还有多少可用的字节，就是data0-offset。
data_avail就是data区域还有多少可用的字节，一开始是等于数据区的大小，随着有数据的写入而相应的减少。
这个binder_io结构的数据可以用来在使用时填写数据，然后再最后在填充到binder_transaction_data结构体中。见右边图。

其他暂不说明，主要注意的是，在某客户端想某service传递一个匿名共享区的fd过来的时候（适合持续传送大量数据，如获取摄像头数据），客户端提交的时候，那个binder_transaction_data中的flags需要有TF_ACCEPT_FDS，起码是flags=TF_ACCEPT_FDS。因为在servcie返回这个fd的时候，在binder驱动内会检查接收者的flags是否有这个TF_ACCEPT_FDS，如果没有，就会报错，而不会进行相应的转换fd，使得在接收者进程的这个新fd，与service中的fd指向同一个file对象。