Binder系统-C程序示例_框架分析

IPC：进程间的通信，远程调用，比如我们的A进程需要打开LED灯，调用led_open/led_ctl方法，但是他是没有权限去操作的，所以进程A通过：1.首先构造一些数据，2.通过IPC发送数据到进程B，然后B进程：1.取出数去，2.调用本地的led_open/led_ctl。表面看起来，我们是通过进程A直接操控LED。

我们可以分析出框架大致如下：
数据的传输有三大要素，分别为源，目的已经数据。找上述的例子中可以如下描述：
源（进程A）：发送数据，A向serviceManager查询led服务，获取一个handle（对硬件操作的服务），该handle指向进程B。
目的（进程B）：B向serviceManager注册LED服务，以便A进程获取
数据：点亮，或者熄灭闪烁等。
源码总体分析
相关问价你主要集中在SDK/frameworks\native\cmds\servicemanager目录下，其中存在文件service_manager.c，bctest.c（半成品），binder.c（封装好的C库）。根据前面的框图，我们分别来了解client，servicemanager，service分别做了，或者需要做什么。前面提到需要注册服务，那么肯定最先运行的是servicemanager，其主做了以下工作：

首先先打开驱动，并且告诉驱动他是servicemanager，这样他就有了驱动的操作权限，并且他是是一个while（1）循环，不停的读取数据，解释数据，如果有需要注册服务，则保存注册的服务到链表中，如果有需要获取服务，则从链表查询服务返回，在没有事情做的时候会处于休眠状态。

下面我们看看service：

最后我们在来看看client：

首先也是open打开驱动，然后向servicemanager查询获取服务，最后向handle（service服务）发送数据。

从上面简单的分析可以看出，service在注册服务的时候没事需要向进程servicemanage发送消息的，client也会向servicemanage进程发送消息获取服务，那么他们怎么知道哪个是servicemanage呢？在servicemanage分析中，他会告诉驱动他是servicemanage（上面已经提及过）。下面我们开始追踪andriod源码，也就是上面提到的那几个文件，看到具体是怎么回事

源码追踪
首先我们打开SDK\frameworks\native\cmds\servicemanager\service_manager.c，我们找到最末尾的main函数：

service_manager.c
service_manager.c（从main函数开始分析）:

//txn->code参数是一个编码，这个编码包含呢很多信息，比如是查找，还是添加服务等等信息，都包含在这个编码中。
svcmgr_handler(struct binder_state *bs,struct binder_transaction_data *txn,struct binder_io *msg,struct binder_io *reply)
	handle = do_find_service(s, len, txn->sender_euid, txn->sender_pid);//根据传入的txn->code，在链表中查找服务，查找到之后返回服务
	do_add_service(bs, s, len, handle, txn->sender_euid,
            allow_isolated, txn->sender_pid) //如果传入的是注册服务，则加入本地链表
            

main()
	binder_open(128*1024); 
		open("/dev/binder", O_RDWR | O_CLOEXEC); //打开驱动binde（前面提到过，进程间的通信都是通过binder）
	binder_become_context_manager(bs); //告诉驱动他是service_manager
	binder_loop(bs, svcmgr_handler); //一个循环，读取处理数据，其中的svcmgr_handler为服务处理函数
		ioctl(bs->fd, BINDER_WRITE_READ, &bwr);  //读取数据
		binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func); //解析数据
			func(bs, txn, &msg, &reply);//处理数据，此处的func就是前面的传入的svcmgr_handler

bctest.c
bctest.c中主要实现了两个功能，注册服务和获取服务，首先我们来看看他的注册服务，我们依旧从main函数开始

main()
	binder_open(128*1024);
		open("/dev/binder", O_RDWR | O_CLOEXEC); //打开驱动binde（前面提到过，进程间的通信都是通过binder）
	svcmgr_publish(bs, svcmgr, argv[1], &token);/*注册服务，其中的svcmgr = BINDER_SERVICE_MANAGER（0），打开驱动binde，进行进程间的通信，
	那么你当然需要告诉binder你是和谁通信，要发给谁，这里的BINDER_SERVICE_MANAGER即为service_manager进程，前面的ervice_manager告诉binder他是service_manager就起到了作用*/
		binder_call(bs, &msg, &reply, target, SVC_MGR_ADD_SERVICE) //构建数据之后，调用该函数，msg：含有服务的名字，reply：service_manager返回的数据 ，target：service_manager进程（0），SVC_MGR_ADD_SERVICE添加服务

以上是注册服务的过程，下面分获取服务过程：

main()
	binder_open(128*1024);
		handle = svcmgr_lookup(bs, svcmgr, "alt_svc_mgr");
			binder_call(bs, &msg, &reply, target, SVC_MGR_CHECK_SERVICE) /*构造数据之后调用该函数，msg：含有服务的名字，reply：service_manager返回的数据（即提供服务的进程） ，
			target：service_manager进程（0），SVC_MGR_CHECK_SERVICE：获取服务*/

分析了注册服务和获取服务的大致过程，我们现在来分析其细致原理，即分析binder_call与之前提到svcmgr_handler函数参数txn中的txn->code，binder_call函数时在binder.c中提供的。

binder.c
我们打开binder.c文件，对binder_call进行分析;

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

binder_call为远程调用，那么我们至少要知道调用那个进程，向那个价进程发送数据，调用那个函数，传递什么参数 ，返回值信息保存在哪里。在上图中已经进行了描述。

那我们这个函数怎么用呢？

1. 构造参数:放在buf中，这buf使用struct binder_io *msg进行描述

2. 调用ioctl发送数据：
		res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);/*其中bwr：struct binder_write_read bwr;
		struct binder_io
		{
		    char *data;            /* pointer to read/write from */
		    binder_size_t *offs;   /* array of offsets */
		    size_t data_avail;     /* bytes available in data buffer */
		    size_t offs_avail;     /* entries available in offsets array */
		
		    char *data0;           /* start of data buffer */
		    binder_size_t *offs0;  /* start of offsets buffer */
		    uint32_t flags;
		    uint32_t unused;
		};*/
			
3. ioctl也会接受数据，收到一个binder_write_read。

不知道大家发现一个问题没有，我们构建的是struct binder_io，但是ioctl需要的是struct binder_write_read bwr，那么他们之间是怎么进行转换的呢？那么他们肯定有一个转换过程。

这些都是大致的一个过程，下面我们开始分析源码：

svcmgr_lookup(struct binder_state *bs, uint32_t target, const char *name)//bctest.c文件
	bio_init(&msg, iodata, sizeof(iodata), 4);
    bio_put_uint32(&msg, 0);  // strict mode header
    bio_put_string16_x(&msg, SVC_MGR_NAME);
    bio_put_string16_x(&msg, name);
	binder_call(struct binder_state *bs,struct binder_io *msg, 	struct binder_io *reply,uint32_t target, uint32_t code)
		------------------------------------------------------
		//对writebu进行构造
		writebuf.cmd = BC_TRANSACTION;
	    writebuf.txn.target.handle = target;
	    writebuf.txn.code = code;
	    writebuf.txn.flags = 0;
	    writebuf.txn.data_size = msg->data - msg->data0;
	    writebuf.txn.offsets_size = ((char*) msg->offs) - ((char*) msg->offs0);
	    writebuf.txn.data.ptr.buffer = (uintptr_t)msg->data0;
	    writebuf.txn.data.ptr.offsets = (uintptr_t)msg->offs0;
	    --------------------------------------------------------
	    --------------------------------------------------------
		struct binder_write_read bwr;
		bwr.write_size = sizeof(writebuf);
	    bwr.write_consumed = 0;
	    bwr.write_buffer = (uintptr_t) &writebuf;
		--------------------------------------------------------

我们发现调用了很多bio_put去构建&msg，放入使用bio_put，那个获取我们可以使用bio_get。构建好msg然后调用binder_call，在该函数中从把msg中的相关成员赋值给writebuf，最后在让bwr.write_buffer指向writebuf，这样就完成了binder_io ms msg到binder_write_read bwr之间的转换，就能通过ioctl驱动binder。
其中write_buffer定义如下：

struct {
        uint32_t cmd;
        struct binder_transaction_data txn;
    } __attribute__((packed)) writebuf;
	//其中txn包括了：handle，code，参数。

小节结语
分析其内部机制之后，我们归纳一下，应该如何去写应用程序，实现进程之间的通信。

client：
	a.binder_open打开驱动，
	b.获取服务handle，
	c.构造参数binder_io，
	d.调用binder_call（handle，code，binder_io），
	e.分析返回的binder_io，取出返回值。
server：
	a.binder_open打开驱动，
	b.注册服务（service）
	c.ioctrl（read）
	d.解析数据binder_write_read,其中存在成员readbuf.binder_transaction_data.txn（前面提到其中包含handle，code，参数）
	e.根据code，决定调用哪个函数，从binder_io取出需要传递的参数，
	f.把返回值转换为binder_io发送给client。