Android系统进程间通信(IPC)机制Binder中的Server启动过程源代码分析(3)

简介:

 Service Manager被唤醒之后,就进入while循环开始处理事务了。这里wait_for_proc_work等于1,并且proc->todo不为空,所以从proc->todo列表中得到第一个工作项:

 

 
 
  1. w = list_first_entry(&proc->todo, struct binder_work, entry); 

 从上面的描述中,我们知道,这个工作项的类型为BINDER_WORK_TRANSACTION,于是通过下面语句得到事务项:

 

 
 
  1. t = container_of(w, struct binder_transaction, work); 

接着就是把事务项t中的数据拷贝到本地局部变量struct binder_transaction_data tr中去了:

 

 
 
  1. if (t->buffer->target_node) {  
  2.     struct binder_node *target_node = t->buffer->target_node;  
  3.     tr.target.ptr = target_node->ptr;  
  4.     tr.cookie =  target_node->cookie;  
  5.     ......  
  6.     cmd = BR_TRANSACTION;  
  7. else {  
  8.     ......  
  9. }  
  10. tr.code = t->code;  
  11. tr.flags = t->flags;  
  12. tr.sender_euid = t->sender_euid;  
  13.  
  14. if (t->from) {  
  15.     struct task_struct *sender = t->from->proc->tsk;  
  16.     tr.sender_pid = task_tgid_nr_ns(sender, current->nsproxy->pid_ns);  
  17. else {  
  18.     tr.sender_pid = 0;  
  19. }  
  20.  
  21. tr.data_size = t->buffer->data_size;  
  22. tr.offsets_size = t->buffer->offsets_size;  
  23. tr.data.ptr.buffer = (void *)t->buffer->data + proc->user_buffer_offset;  
  24. tr.data.ptr.offsets = tr.data.ptr.buffer + ALIGN(t->buffer->data_size, sizeof(void *)); 

  这里有一个非常重要的地方,是Binder进程间通信机制的精髓所在:

 

 
 
  1. tr.data.ptr.buffer = (void *)t->buffer->data + proc->user_buffer_offset;  
  2. tr.data.ptr.offsets = tr.data.ptr.buffer + ALIGN(t->buffer->data_size, sizeof(void *)); 

 t->buffer->data所指向的地址是内核空间的,现在要把数据返回给Service Manager进程的用户空间,而Service Manager进程的用户空间是不能访问内核空间的数据的,所以这里要作一下处理。怎么处理呢?我们在学面向对象语言的时候,对象的拷贝有深拷贝和浅拷贝之分,深拷贝是把另外分配一块新内存,然后把原始对象的内容搬过去,浅拷贝是并没有为新对象分配一块新空间,而只是分配一个引用,而个引用指向原始对象。Binder机制用的是类似浅拷贝的方法,通过在用户空间分配一个虚拟地址,然后让这个用户空间虚拟地址与 t->buffer->data这个内核空间虚拟地址指向同一个物理地址,这样就可以实现浅拷贝了。怎么样用户空间和内核空间的虚拟地址同时指向同一个物理地址呢?请参考前面一篇文章浅谈Service Manager成为Android进程间通信(IPC)机制Binder守护进程之路,那里有详细描述。这里只要将t->buffer->data加上一个偏移值proc->user_buffer_offset就可以得到t->buffer->data对应的用户空间虚拟地址了。调整了tr.data.ptr.buffer的值之后,不要忘记也要一起调整tr.data.ptr.offsets的值。
 

 

        接着就是把tr的内容拷贝到用户传进来的缓冲区去了,指针ptr指向这个用户缓冲区的地址:

 

 
 
  1. if (put_user(cmd, (uint32_t __user *)ptr))  
  2.     return -EFAULT;  
  3. ptr += sizeof(uint32_t);  
  4. if (copy_to_user(ptr, &tr, sizeof(tr)))  
  5.     return -EFAULT;  
  6. ptr += sizeof(tr); 

这里可以看出,这里只是对作tr.data.ptr.bufferr和tr.data.ptr.offsets的内容作了浅拷贝。

 

         最后,由于已经处理了这个事务,要把它从todo列表中删除:

 

 
 
  
  1. list_del(&t->work.entry);  
  2. t->buffer->allow_user_free = 1;  
  3. if (cmd == BR_TRANSACTION && !(t->flags & TF_ONE_WAY)) {  
  4.     t->to_parent = thread->transaction_stack;  
  5.     t->to_thread = thread;  
  6.     thread->transaction_stack = t;  
  7. else {  
  8.     t->buffer->transaction = NULL;  
  9.     kfree(t);  
  10.     binder_stats.obj_deleted[BINDER_STAT_TRANSACTION]++;  

 注意,这里的cmd == BR_TRANSACTION && !(t->flags & TF_ONE_WAY)为true,表明这个事务虽然在驱动程序中已经处理完了,但是它仍然要等待Service Manager完成之后,给驱动程序一个确认,也就是需要等待回复,于是把当前事务t放在thread->transaction_stack队列的头部:

 

 
 
  1. t->to_parent = thread->transaction_stack;  
  2. t->to_thread = thread;  
  3. thread->transaction_stack = t; 

  如果cmd == BR_TRANSACTION && !(t->flags & TF_ONE_WAY)为false,那就不需要等待回复了,直接把事务t删掉。
 

 

         这个while最后通过一个break跳了出来,最后返回到binder_ioctl函数中:
 

 
 
  1. static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)  
  2. {  
  3.     int ret;  
  4.     struct binder_proc *proc = filp->private_data;  
  5.     struct binder_thread *thread;  
  6.     unsigned int size = _IOC_SIZE(cmd);  
  7.     void __user *ubuf = (void __user *)arg;  
  8.  
  9.     ......  
  10.  
  11.     switch (cmd) {  
  12.     case BINDER_WRITE_READ: {  
  13.         struct binder_write_read bwr;  
  14.         if (size != sizeof(struct binder_write_read)) {  
  15.             ret = -EINVAL;  
  16.             goto err;  
  17.         }  
  18.         if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {  
  19.             ret = -EFAULT;  
  20.             goto err;  
  21.         }  
  22.         ......  
  23.         if (bwr.read_size > 0) {  
  24.             ret = binder_thread_read(proc, thread, (void __user *)bwr.read_buffer, bwr.read_size, &bwr.read_consumed, filp->f_flags & O_NONBLOCK);  
  25.             if (!list_empty(&proc->todo))  
  26.                 wake_up_interruptible(&proc->wait);  
  27.             if (ret < 0) {  
  28.                 if (copy_to_user(ubuf, &bwr, sizeof(bwr)))  
  29.                     ret = -EFAULT;  
  30.                 goto err;  
  31.             }  
  32.         }  
  33.         ......  
  34.         if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {  
  35.             ret = -EFAULT;  
  36.             goto err;  
  37.         }  
  38.         break;  
  39.         }  
  40.     ......  
  41.     default:  
  42.         ret = -EINVAL;  
  43.         goto err;  
  44.     }  
  45.     ret = 0;  
  46. err:  
  47.     ......  
  48.     return ret;  

从binder_thread_read返回来后,再看看proc->todo是否还有事务等待处理,如果是,就把睡眠在proc->wait队列的线程唤醒来处理。最后,把本地变量struct binder_write_read bwr的内容拷贝回到用户传进来的缓冲区中,就返回了。

 

        这里就是返回到frameworks/base/cmds/servicemanager/binder.c文件中的binder_loop函数了:

 

 
 
  1. void binder_loop(struct binder_state *bs, binder_handler func)  
  2. {  
  3.     int res;  
  4.     struct binder_write_read bwr;  
  5.     unsigned readbuf[32];  
  6.  
  7.     bwr.write_size = 0;  
  8.     bwr.write_consumed = 0;  
  9.     bwr.write_buffer = 0;  
  10.       
  11.     readbuf[0] = BC_ENTER_LOOPER;  
  12.     binder_write(bs, readbuf, sizeof(unsigned));  
  13.  
  14.     for (;;) {  
  15.         bwr.read_size = sizeof(readbuf);  
  16.         bwr.read_consumed = 0;  
  17.         bwr.read_buffer = (unsigned) readbuf;  
  18.  
  19.         res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);  
  20.  
  21.         if (res < 0) {  
  22.             LOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));  
  23.             break;  
  24.         }  
  25.  
  26.         res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);  
  27.         if (res == 0) {  
  28.             LOGE("binder_loop: unexpected reply?!\n");  
  29.             break;  
  30.         }  
  31.         if (res < 0) {  
  32.             LOGE("binder_loop: io error %d %s\n", res, strerror(errno));  
  33.             break;  
  34.         }  
  35.     }  

返回来的数据都放在readbuf中,接着调用binder_parse进行解析:

 

 
 
  1. int binder_parse(struct binder_state *bs, struct binder_io *bio,  
  2.                  uint32_t *ptr, uint32_t size, binder_handler func)  
  3. {  
  4.     int r = 1;  
  5.     uint32_t *end = ptr + (size / 4);  
  6.  
  7.     while (ptr < end) {  
  8.         uint32_t cmd = *ptr++;  
  9.         ......  
  10.         case BR_TRANSACTION: {  
  11.             struct binder_txn *txn = (void *) ptr;  
  12.             if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_txn)) {  
  13.                 LOGE("parse: txn too small!\n");  
  14.                 return -1;  
  15.             }  
  16.             binder_dump_txn(txn);  
  17.             if (func) {  
  18.                 unsigned rdata[256/4];  
  19.                 struct binder_io msg;  
  20.                 struct binder_io reply;  
  21.                 int res;  
  22.  
  23.                 bio_init(&reply, rdata, sizeof(rdata), 4);  
  24.                 bio_init_from_txn(&msg, txn);  
  25.                 res = func(bs, txn, &msg, &reply);  
  26.                 binder_send_reply(bs, &reply, txn->data, res);  
  27.             }  
  28.             ptr += sizeof(*txn) / sizeof(uint32_t);  
  29.             break;  
  30.                              }  
  31.         ......  
  32.         default:  
  33.             LOGE("parse: OOPS %d\n", cmd);  
  34.             return -1;  
  35.         }  
  36.     }  
  37.  
  38.     return r;  

  首先把从Binder驱动程序读出来的数据转换为一个struct binder_txn结构体,保存在txn本地变量中,struct binder_txn定义在frameworks/base/cmds/servicemanager/binder.h文件中:

 

 
 
  1. struct binder_txn  
  2. {  
  3.     void *target;  
  4.     void *cookie;  
  5.     uint32_t code;  
  6.     uint32_t flags;  
  7.  
  8.     uint32_t sender_pid;  
  9.     uint32_t sender_euid;  
  10.  
  11.     uint32_t data_size;  
  12.     uint32_t offs_size;  
  13.     void *data;  
  14.     void *offs;  
  15. }; 

函数中还用到了另外一个数据结构struct binder_io,也是定义在frameworks/base/cmds/servicemanager/binder.h文件中:

 

 
 
  1. struct binder_io  
  2. {  
  3.     char *data;            /* pointer to read/write from */  
  4.     uint32_t *offs;        /* array of offsets */  
  5.     uint32_t data_avail;   /* bytes available in data buffer */  
  6.     uint32_t offs_avail;   /* entries available in offsets array */  
  7.  
  8.     char *data0;           /* start of data buffer */  
  9.     uint32_t *offs0;       /* start of offsets buffer */  
  10.     uint32_t flags;  
  11.     uint32_t unused;  
  12. }; 

接着往下看,函数调bio_init来初始化reply变量:

 

 
 
  1. void bio_init(struct binder_io *bio, void *data,  
  2.               uint32_t maxdata, uint32_t maxoffs)  
  3. {  
  4.     uint32_t n = maxoffs * sizeof(uint32_t);  
  5.  
  6.     if (n > maxdata) {  
  7.         bio->flags = BIO_F_OVERFLOW;  
  8.         bio->data_avail = 0;  
  9.         bio->offs_avail = 0;  
  10.         return;  
  11.     }  
  12.  
  13.     bio->data = bio->data0 = data + n;  
  14.     bio->offs = bio->offs0 = data;  
  15.     bio->data_avail = maxdata - n;  
  16.     bio->offs_avail = maxoffs;  
  17.     bio->flags = 0;  

接着又调用bio_init_from_txn来初始化msg变量:

 

 
 
  1. void bio_init_from_txn(struct binder_io *bio, struct binder_txn *txn)  
  2. {  
  3.     bio->data = bio->data0 = txn->data;  
  4.     bio->offs = bio->offs0 = txn->offs;  
  5.     bio->data_avail = txn->data_size;  
  6.     bio->offs_avail = txn->offs_size / 4;  
  7.     bio->flags = BIO_F_SHARED;  

   最后,真正进行处理的函数是从参数中传进来的函数指针func,这里就是定义在frameworks/base/cmds/servicemanager/service_manager.c文件中的svcmgr_handler函数:

 

 
 
  1. int svcmgr_handler(struct binder_state *bs,  
  2.                    struct binder_txn *txn,  
  3.                    struct binder_io *msg,  
  4.                    struct binder_io *reply)  
  5. {  
  6.     struct svcinfo *si;  
  7.     uint16_t *s;  
  8.     unsigned len;  
  9.     void *ptr;  
  10.     uint32_t strict_policy;  
  11.  
  12.     if (txn->target != svcmgr_handle)  
  13.         return -1;  
  14.  
  15.     // Equivalent to Parcel::enforceInterface(), reading the RPC  
  16.     // header with the strict mode policy mask and the interface name.  
  17.     // Note that we ignore the strict_policy and don't propagate it  
  18.     // further (since we do no outbound RPCs anyway).  
  19.     strict_policy = bio_get_uint32(msg);  
  20.     s = bio_get_string16(msg, &len);  
  21.     if ((len != (sizeof(svcmgr_id) / 2)) ||  
  22.         memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {  
  23.             fprintf(stderr,"invalid id %s\n", str8(s));  
  24.             return -1;  
  25.     }  
  26.  
  27.     switch(txn->code) {  
  28.     ......  
  29.     case SVC_MGR_ADD_SERVICE:  
  30.         s = bio_get_string16(msg, &len);  
  31.         ptr = bio_get_ref(msg);  
  32.         if (do_add_service(bs, s, len, ptr, txn->sender_euid))  
  33.             return -1;  
  34.         break;  
  35.     ......  
  36.     }  
  37.  
  38.     bio_put_uint32(reply, 0);  
  39.     return 0;  

   回忆一下,在BpServiceManager::addService时,传给Binder驱动程序的参数为:

 

 
 
  1. writeInt32(IPCThreadState::self()->getStrictModePolicy() | STRICT_MODE_PENALTY_GATHER);  
  2. writeString16("android.os.IServiceManager");  
  3. writeString16("media.player");  
  4. writeStrongBinder(new MediaPlayerService()); 

这里的语句:

 

 
 
  1. strict_policy = bio_get_uint32(msg);  
  2. s = bio_get_string16(msg, &len);  
  3. s = bio_get_string16(msg, &len);  
  4. ptr = bio_get_ref(msg); 

 就是依次把它们读取出来了,这里,我们只要看一下bio_get_ref的实现。先看一个数据结构struct binder_obj的定义:

 

 
 
  1. struct binder_object  
  2. {  
  3.     uint32_t type;  
  4.     uint32_t flags;  
  5.     void *pointer;  
  6.     void *cookie;  
  7. }; 

这个结构体其实就是对应struct flat_binder_obj的。

 

        接着看bio_get_ref实现:

 

 
 
  1. void *bio_get_ref(struct binder_io *bio)  
  2. {  
  3.     struct binder_object *obj;  
  4.  
  5.     obj = _bio_get_obj(bio);  
  6.     if (!obj)  
  7.         return 0;  
  8.  
  9.     if (obj->type == BINDER_TYPE_HANDLE)  
  10.         return obj->pointer;  
  11.  
  12.     return 0;  

bio_get_obj这个函数就不跟进去看了,它的作用就是从binder_io中取得第一个还没取获取过的binder_object。在这个场景下,就是我们最开始传过来代表MediaPlayerService的flat_binder_obj了,这个原始的flat_binder_obj的type为BINDER_TYPE_BINDER,binder为指向MediaPlayerService的弱引用的地址。在前面我们说过,在Binder驱动驱动程序里面,会把这个flat_binder_obj的type改为BINDER_TYPE_HANDLE,handle改为一个句柄值。这里的handle值就等于obj->pointer的值。

 

        回到svcmgr_handler函数,调用do_add_service进一步处理:

 

 
 
  1. int do_add_service(struct binder_state *bs,  
  2.                    uint16_t *s, unsigned len,  
  3.                    void *ptr, unsigned uid)  
  4. {  
  5.     struct svcinfo *si;  
  6. //    LOGI("add_service('%s',%p) uid=%d\n", str8(s), ptr, uid);  
  7.  
  8.     if (!ptr || (len == 0) || (len > 127))  
  9.         return -1;  
  10.  
  11.     if (!svc_can_register(uid, s)) {  
  12.         LOGE("add_service('%s',%p) uid=%d - PERMISSION DENIED\n",  
  13.              str8(s), ptr, uid);  
  14.         return -1;  
  15.     }  
  16.  
  17.     si = find_svc(s, len);  
  18.     if (si) {  
  19.         if (si->ptr) {  
  20.             LOGE("add_service('%s',%p) uid=%d - ALREADY REGISTERED\n",  
  21.                  str8(s), ptr, uid);  
  22.             return -1;  
  23.         }  
  24.         si->ptr = ptr;  
  25.     } else {  
  26.         si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));  
  27.         if (!si) {  
  28.             LOGE("add_service('%s',%p) uid=%d - OUT OF MEMORY\n",  
  29.                  str8(s), ptr, uid);  
  30.             return -1;  
  31.         }  
  32.         si->ptr = ptr;  
  33.         si->len = len;  
  34.         memcpy(si->name, s, (len + 1) * sizeof(uint16_t));  
  35.         si->name[len] = '\0';  
  36.         si->death.func = svcinfo_death;  
  37.         si->death.ptr = si;  
  38.         si->next = svclist;  
  39.         svclist = si;  
  40.     }  
  41.  
  42.     binder_acquire(bs, ptr);  
  43.     binder_link_to_death(bs, ptr, &si->death);  
  44.     return 0;  

   





本文转自 Luoshengyang 51CTO博客,原文链接:http://blog.51cto.com/shyluo/964541,如需转载请自行联系原作者

目录
相关文章
|
2月前
麒麟系统mate-indicators进程占用内存过高问题解决
【10月更文挑战第7天】麒麟系统mate-indicators进程占用内存过高问题解决
308 2
|
8天前
|
存储 监控 Linux
嵌入式Linux系统编程 — 5.3 times、clock函数获取进程时间
在嵌入式Linux系统编程中,`times`和 `clock`函数是获取进程时间的两个重要工具。`times`函数提供了更详细的进程和子进程时间信息,而 `clock`函数则提供了更简单的处理器时间获取方法。根据具体需求选择合适的函数,可以更有效地进行性能分析和资源管理。通过本文的介绍,希望能帮助您更好地理解和使用这两个函数,提高嵌入式系统编程的效率和效果。
61 13
|
24天前
|
调度 开发者
核心概念解析:进程与线程的对比分析
在操作系统和计算机编程领域,进程和线程是两个基本而核心的概念。它们是程序执行和资源管理的基础,但它们之间存在显著的差异。本文将深入探讨进程与线程的区别,并分析它们在现代软件开发中的应用和重要性。
43 4
|
1月前
|
网络协议 Linux 虚拟化
如何在 Linux 系统中查看进程的详细信息?
如何在 Linux 系统中查看进程的详细信息?
90 1
|
1月前
|
Linux
如何在 Linux 系统中查看进程占用的内存?
如何在 Linux 系统中查看进程占用的内存?
|
1月前
|
运维 JavaScript jenkins
鸿蒙5.0版开发:分析CppCrash(进程崩溃)
在HarmonyOS 5.0中,CppCrash指C/C++运行时崩溃,常见原因包括空指针、数组越界等。系统提供基于posix信号机制的异常检测能力,生成详细日志辅助定位。本文详解CppCrash分析方法,涵盖异常检测、问题定位思路及案例分析。
55 4
|
1月前
|
运维 监控 JavaScript
鸿蒙next版开发:分析JS Crash(进程崩溃)
在HarmonyOS 5.0中,JS Crash指未处理的JavaScript异常导致应用意外退出。本文详细介绍如何分析JS Crash,包括异常捕获、日志分析和典型案例,帮助开发者定位问题、修复错误,提升应用稳定性。通过DevEco Studio收集日志,结合HiChecker工具,有效解决JS Crash问题。
53 4
|
1月前
|
消息中间件 存储 Linux
|
2月前
麒麟系统mate-indicators进程占用内存过高问题解决
【10月更文挑战第5天】麒麟系统mate-indicators进程占用内存过高问题解决
200 0
|
5月前
|
运维 关系型数据库 MySQL
掌握taskset:优化你的Linux进程,提升系统性能
在多核处理器成为现代计算标准的今天,运维人员和性能调优人员面临着如何有效利用这些处理能力的挑战。优化进程运行的位置不仅可以提高性能,还能更好地管理和分配系统资源。 其中,taskset命令是一个强大的工具,它允许管理员将进程绑定到特定的CPU核心,减少上下文切换的开销,从而提升整体效率。
掌握taskset:优化你的Linux进程,提升系统性能

相关实验场景

更多