Android系统中Binder子系统有什么用

90次阅读
没有评论

共计 20348 个字符,预计需要花费 51 分钟才能阅读完成。

这篇文章主要介绍了 Android 系统中 Binder 子系统有什么用,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让丸趣 TV 小编带着大家一起了解一下。

 binder 系统的核心是另种通信方式:IPC 和 RPC。IPC 是 src A 直接发给 des B,而 RPC 是 src A 通过远程函数调用 des B。

 1、IPC 通信的方式有三个要素:

 1. 发送源:A;

 2. 目的:B 向 servicemanger 注册 led 服务,A 向 servicemanger 查询 led 服务,得到一个 handle;

 3. 数据本身:char buf[512];

 2、RPC 通信方式是远程函数调用:

 1. 调用的是哪个函数:sever 的函数编号;

 2. 传给它什么参数,返回值。通过 IPC 的 buf 传输。

 example:LED 传输。IPC 方式是从 A 直接发送给 B;而 RPC 方式是 led_open、led_ctl 进行封装数据,然后发送给 B,在 B 那边调用 led_open,led_ctl 再次取出数据。

  我们先来大概介绍下 client、servicemanger、server 三个的作用。

 client:

 1. 打开驱动;

 2. 获取服务:向 servicemanger 查询服务,获得一个 handle;

 3. 向 handle 发送数据。

 servicemanger:

 1. 打开驱动;

 2. 告诉驱动,它是“servicemanger”;

 3. while(1) {

  读驱动获取数据;

  解析数据;

  调用:a. 注册服务:在链表中记录服务名;

  b. 获取服务:b.1 在链表中查询有无此服务;b.2 返回“server 进程”的 handle。

 };

 server:

 1. 打开驱动;

 2. 注册服务:向 servicemanger 发送服务;

 3. while(1) {

  读驱动获取数据;

  解析数据;

  调用对应函数。

 };

  它们三个都是基于 binder 驱动进行工作。我们先来看看 service_manger.c 文件,mian 函数大体如下

int main(int argc, char **argv)
 struct binder_state *bs;
 bs = binder_open(128*1024); //  对应上面的第一步。打开驱动
 if (!bs) {
 ALOGE( failed to open binder driver\n 
 return -1;
 }
 if (binder_become_context_manager(bs)) { ALOGE( cannot become context manager (%s)\n , strerror(errno));
 return -1;
 }
 selinux_enabled = is_selinux_enabled();
 sehandle = selinux_android_service_context_handle();
 if (selinux_enabled   0) { if (sehandle == NULL) {
 ALOGE( SELinux: Failed to acquire sehandle. Aborting.\n 
 abort();
 }
 if (getcon( service_manager_context) != 0) {
 ALOGE( SELinux: Failed to acquire service_manager context. Aborting.\n 
 abort();
 }
 }
 union selinux_callback cb;
 cb.func_audit = audit_callback;
 selinux_set_callback(SELINUX_CB_AUDIT, cb);
 cb.func_log = selinux_log_callback;
 selinux_set_callback(SELINUX_CB_LOG, cb);
 svcmgr_handle = BINDER_SERVICE_MANAGER; //  对应上面的第二步。告诉驱动,它是  ServiceManager
 binder_loop(bs, svcmgr_handler); //  对应上面的第三步。 while  循环所做的事情
 return 0;
}

  我们再来看看 binder.c(对应于上面的 server),其中 binder_loop 函数就在此文件中。我们来看看 binder_loop 函数所做的事情,code 如下

void binder_loop(struct binder_state *bs, binder_handler func)
 int res;
 struct binder_write_read bwr;
 uint32_t readbuf[32];
 bwr.write_size = 0;
 bwr.write_consumed = 0;
 bwr.write_buffer = 0;
 readbuf[0] = BC_ENTER_LOOPER;
 binder_write(bs, readbuf, sizeof(uint32_t));
 for (;;) { bwr.read_size = sizeof(readbuf);
 bwr.read_consumed = 0;
 bwr.read_buffer = (uintptr_t) readbuf;
 res = ioctl(bs- fd, BINDER_WRITE_READ,  bwr); //  读取驱动获得数据
 if (res   0) { ALOGE( binder_loop: ioctl failed (%s)\n , strerror(errno));
 break;
 }
 res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func); //  解析数据
 if (res == 0) {
 ALOGE( binder_loop: unexpected reply?!\n 
 break;
 }
 if (res   0) { ALOGE( binder_loop: io error %d %s\n , res, strerror(errno));
 break;
 }
 }
}

  我们再来看看 bctest.c 文件(对应于上面的 client),code 如下

int main(int argc, char **argv)
 int fd;
 struct binder_state *bs;
 uint32_t svcmgr = BINDER_SERVICE_MANAGER;
 uint32_t handle;
 bs = binder_open(128*1024);
 if (!bs) {
 fprintf(stderr,  failed to open binder driver\n 
 return -1;
 }
 argc--;
 argv++;
 while (argc   0) { if (!strcmp(argv[0], alt )) {
 handle = svcmgr_lookup(bs, svcmgr,  alt_svc_mgr 
 if (!handle) {
 fprintf(stderr, cannot find alt_svc_mgr\n 
 return -1;
 }
 svcmgr = handle;
 fprintf(stderr, svcmgr is via %x\n , handle);
 } else if (!strcmp(argv[0], lookup )) { if (argc   2) {
 fprintf(stderr, argument required\n 
 return -1;
 }
 handle = svcmgr_lookup(bs, svcmgr, argv[1]); //  获取服务
 fprintf(stderr, lookup(%s) = %x\n , argv[1], handle);
 argc--;
 argv++;
 } else if (!strcmp(argv[0], publish )) { if (argc   2) {
 fprintf(stderr, argument required\n 
 return -1;
 }
 svcmgr_publish(bs, svcmgr, argv[1],  token); //  注册服务
 argc--;
 argv++;
 } else { fprintf(stderr, unknown command %s\n , argv[0]);
 return -1;
 }
 argc--;
 argv++;
 }
 return 0;
}

  先来看看 svcmgr_lookup 函数是怎么来获取服务的,code 如下

uint32_t svcmgr_lookup(struct binder_state *bs, uint32_t target, const char *name)
 uint32_t handle;
 unsigned iodata[512/4];
 struct binder_io msg, reply;
 //  构造  binder_io
 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);
 if (binder_call(bs,  msg,  reply, target, SVC_MGR_CHECK_SERVICE)) //  获取服务
 return 0;
 handle = bio_get_ref(reply);
 if (handle)
 binder_acquire(bs, handle);
 binder_done(bs,  msg,  reply);
 return handle;
}

  我们看到其中核心函数是 binder_call 函数。再来看看 svcmgr_publish 函数是怎么来注册服务的,code 如下

int svcmgr_publish(struct binder_state *bs, uint32_t target, const char *name, void *ptr)
 int status;
 unsigned iodata[512/4];
 struct binder_io msg, reply;
 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);
 bio_put_obj(msg, ptr);
 if (binder_call(bs,  msg,  reply, target, SVC_MGR_ADD_SERVICE)) //  注册服务
 return -1;
 status = bio_get_uint32(reply);
 binder_done(bs,  msg,  reply);
 return status;
}

  其中核心函数还是 binder_call 函数。binder_call 函数的参数作用分别是:1、远程调用;2、向谁发送数据;3、调用那个函数;4、提供什么参数;5、返回值。

  那么 binder_call 函数中的参数作用如下:

 1、bs 是一个结构体,代表远程调用;

 2、msg 中含有服务的名字;

 3、reply 中含有 servicemanager 回复的数据, 表示提供服务的进程;

 4、target 代表是的
0,表示 servicemanager, (if (target == 0));

 5、SVC_MGR_CHECK_SERVICE
表示要调用 servicemanager 中的 getservice 函数。

  下来我们具体来看看 binder_call 的实现

int binder_call(struct binder_state *bs,
 struct binder_io *msg, struct binder_io *reply,
 uint32_t target, uint32_t code)
 int res;
 struct binder_write_read bwr;
 struct {
 uint32_t cmd;
 struct binder_transaction_data txn;
 } __attribute__((packed)) writebuf;
 unsigned readbuf[32];
 if (msg- flags   BIO_F_OVERFLOW) {
 fprintf(stderr, binder: txn buffer overflow\n 
 goto fail;
 }
 //  构造参数
 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;
 bwr.write_size = sizeof(writebuf);
 bwr.write_consumed = 0;
 bwr.write_buffer = (uintptr_t)  writebuf;
 hexdump(msg- data0, msg- data - msg- data0);
 for (;;) { bwr.read_size = sizeof(readbuf);
 bwr.read_consumed = 0;
 bwr.read_buffer = (uintptr_t) readbuf;
 res = ioctl(bs- fd, BINDER_WRITE_READ,  bwr); //  调用  ioctl  发数据
 if (res   0) { fprintf(stderr, binder: ioctl failed (%s)\n , strerror(errno));
 goto fail;
 }
 res = binder_parse(bs, reply, (uintptr_t) readbuf, bwr.read_consumed, 0);
 if (res == 0) return 0;
 if (res   0) goto fail;
 }
fail:
 memset(reply, 0, sizeof(*reply));
 reply- flags |= BIO_F_IOERROR;
 return -1;
}

  我们看到在 writebuf 中构造参数,构造参数放在 buf 中,用 binder_io 来描述。先把 binder_io 转换为 binder_write_read;在 ioctl 中调用它来发送数据;最后在 binder_parse 函数将 binder_write_read 转换为 binder_io。

  下来我们再来看看 IPC 是怎么进行数据交互的。我们前面说了,IPC 传输方式有三个要素:

 1. 源(自己)

 2. 目的:用 handle 表示“服务”,即向实现该“服务”的进程发送数据;handle 是“服务”的引用。

 3. 数据。

 handle 是进程 A 对进程 B 提供的服务 S 的引用。

  下来我们来解释下上面那句话中的一些关键词:

  引用,code 如下

struct binder_ref {
 /* Lookups needed: */
 /* node + proc =  ref (transaction) */
 /* desc + proc =  ref (transaction, inc/dec ref) */
 /* node =  refs + procs (proc exit) */
 int debug_id;
 struct rb_node rb_node_desc;
 struct rb_node rb_node_node;
 struct hlist_node node_entry;
 struct binder_proc *proc;
 struct binder_node *node;
 uint32_t desc;
 int strong;
 int weak;
 struct binder_ref_death *death;
};

  我们看到 binder_ref 结构体中有个 binder_node 结构体,这个 binder_node 便指的是服务 S。code 如下

struct binder_node {
 int debug_id;
 struct binder_work work;
 union {
 struct rb_node rb_node;
 struct hlist_node dead_node;
 };
 struct binder_proc *proc;
 struct hlist_head refs;
 int internal_strong_refs;
 int local_weak_refs;
 int local_strong_refs;
 void __user *ptr;
 void __user *cookie;
 unsigned has_strong_ref:1;
 unsigned pending_strong_ref:1;
 unsigned has_weak_ref:1;
 unsigned pending_weak_ref:1;
 unsigned has_async_transaction:1;
 unsigned accept_fds:1;
 unsigned min_priority:8;
 struct list_head async_todo;
};

  在 binder_node 结构体中有个 binder_proc 结构体,这个 binder_proc 便指的是进程 B。code 如下

struct binder_proc {
 struct hlist_node proc_node;
 struct rb_root threads;
 struct rb_root nodes;
 struct rb_root refs_by_desc;
 struct rb_root refs_by_node;
 int pid;
 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;
 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;
 wait_queue_head_t wait;
 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;
};

  在 binder_proc 结构体中有个 threads 结构体,这个 threads 便指的是多线程。code 如下

struct binder_thread {
 struct binder_proc *proc;
 struct rb_node rb_node;
 int pid;
 int looper;
 struct binder_transaction *transaction_stack;
 struct list_head todo;
 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;
 struct binder_stats stats;
};

  现在我们就知道多线程是怎么来进行信息的传输了。

 server 传入一个 flat_binder_object 给驱动:

 1. 在内核态驱动里为每个服务创建 binder_node。binder_node.proc = server 进程

 2. service_manger 在驱动中创建 binder_ref,引用 binder_node。binder_ref.desc = 1,2,3…;在用户态创建服务链表(name,handle),handle 指的是前面的 binder_ref.desc

 3. client 向 service_manger 查询服务,传 name

 4. service_manger 返回 handle 给驱动程序

 5. 驱动程序在 service_manger 的 binder_ref 红黑树中根据 handle 找到 binder_ref,再根据 binder_ref.node 找到 binder_node,最后给 client 创建新的 binder_ref(它的 desc 从 1 开始)。驱动返回 desc 给 client,它即为 handle

 6. client:驱动根据 handle 找到 binder_ref,根据 binder_ref 找到 binder_node,最后根据 binder_node 找到 server 进程。

  下来我们来看看数据传输过程(进程切换)

 client 到 server,是先写后读:

 1. client 构造数据,调用 ioctl 发数据;

 2. 驱动里根据 handle 找到 server 进程;

 3. 把数据放入进程的 binder_proc.todo;

 4. 休眠;

 5. 被唤醒;

 6. 从 todo 链表中取出数据,返回用户空间。

 server 端,先读后写:

 1. 读数据休眠;

 2. 被唤醒;

 3. 从 todo 链表中取出数据,返回用户空间;

 4. 处理数据;

 5. 把结果写给 client,也就是放入 client 的 binder_proc.todo 链表,唤醒 client。

  那么一般情况下,数据是如何进行复制的呢?一般方法,需要 2 次复制。

 1. client 构造数据;

 2. 驱动:copy_from_user

 3. server:3.1 驱动,copy_to_user

  3.2 用户态处理

 binder 复制数据的方法是只需 1 次复制。

 1. server 进行 mmap 映射,用户态可以直接访问驱动中的某块内存。

 2. client 构造数据,驱动:copy_from_user

 3. server 可以在用户态直接使用数据。

  但是值得注意的是:在 binder 方法中,从 test_client 到 test_server 端有个数据需复制 2 次。在 ioctl 时,binder_write_read 结构体先 copy_from_user 到某个内存局部变量,然后再 copy_to_user 到 test_server 端。别的数据都是从 test_cliet 端 copy_from_user 到内核内存,然后 test_server 端直接通过 mmap 可以访问到内核内存,不用经过 copy_to_user 复制。因此 binder 系统在进行通信时效率能提高一倍。

    接下来我们来看看服务注册过程,我们先来看看 binder 的驱动框架。我们在 binder_init 函数中看到它是使用 misc_register 来注册的,说明它是 misc 设备驱动。通过注册 binder_miscdev 结构体以达到调用 binder_fops 结构体,在 binder_fops 结构体中就含有 binder 驱动各种操作的入口函数。具体代码如下

static int __init binder_init(void)
 int ret;
 binder_deferred_workqueue = create_singlethread_workqueue( binder 
 if (!binder_deferred_workqueue)
 return -ENOMEM;
 binder_debugfs_dir_entry_root = debugfs_create_dir(binder , NULL);
 if (binder_debugfs_dir_entry_root)
 binder_debugfs_dir_entry_proc = debugfs_create_dir( proc ,
 binder_debugfs_dir_entry_root);
 ret = misc_register(binder_miscdev);
 if (binder_debugfs_dir_entry_root) {
 debugfs_create_file( state ,
 S_IRUGO,
 binder_debugfs_dir_entry_root,
 NULL,
  binder_state_fops);
 debugfs_create_file( stats ,
 S_IRUGO,
 binder_debugfs_dir_entry_root,
 NULL,
  binder_stats_fops);
 debugfs_create_file( transactions ,
 S_IRUGO,
 binder_debugfs_dir_entry_root,
 NULL,
  binder_transactions_fops);
 debugfs_create_file( transaction_log ,
 S_IRUGO,
 binder_debugfs_dir_entry_root,
  binder_transaction_log,
  binder_transaction_log_fops);
 debugfs_create_file( failed_transaction_log ,
 S_IRUGO,
 binder_debugfs_dir_entry_root,
  binder_transaction_log_failed,
  binder_transaction_log_fops);
 }
 return ret;
}

 binder_miscdev 代码如下

static struct miscdevice binder_miscdev = {
 .minor = MISC_DYNAMIC_MINOR,
 .name =  binder ,
 .fops =  binder_fops
};

 binder_fops 代码如下

static const struct file_operations binder_fops = {
 .owner = THIS_MODULE,
 .poll = binder_poll,
 .unlocked_ioctl = binder_ioctl,
 .mmap = binder_mmap,
 .open = binder_open,
 .flush = binder_flush,
 .release = binder_release,
};

  在 service_manger 中,打开 binder driver,紧接着 ioctl,最后再 mmap。代码如下

struct binder_state *binder_open(size_t mapsize)
 struct binder_state *bs;
 struct binder_version vers;
 bs = malloc(sizeof(*bs));
 if (!bs) {
 errno = ENOMEM;
 return NULL;
 }
 bs- fd = open(/dev/binder , O_RDWR);
 if (bs- fd   0) { fprintf(stderr, binder: cannot open device (%s)\n ,
 strerror(errno));
 goto fail_open;
 }
 if ((ioctl(bs- fd, BINDER_VERSION,  vers) == -1) ||
 (vers.protocol_version != BINDER_CURRENT_PROTOCOL_VERSION)) {
 fprintf(stderr,  binder: driver version differs from user space\n 
 goto fail_open;
 }
 bs- mapsize = mapsize;
 bs- mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs- fd, 0);
 if (bs- mapped == MAP_FAILED) { fprintf(stderr, binder: cannot map device (%s)\n ,
 strerror(errno));
 goto fail_map;
 }
 return bs;
fail_map:
 close(bs- 
fail_open:
 free(bs);
 return NULL;
}

  做完这些操作后,service_manger 便会进入到 binder_loop 循环中。在 binder_loop 函数中,readbuf 中存储的是 BC_ENTER_LOOPER,接着 ioctl BINDER_WRITE_READ,再进行 binder_parse 解析。代码如下

void binder_loop(struct binder_state *bs, binder_handler func)
 int res;
 struct binder_write_read bwr;
 uint32_t readbuf[32];
 bwr.write_size = 0;
 bwr.write_consumed = 0;
 bwr.write_buffer = 0;
 readbuf[0] = BC_ENTER_LOOPER;
 binder_write(bs, readbuf, sizeof(uint32_t));
 for (;;) { bwr.read_size = sizeof(readbuf);
 bwr.read_consumed = 0;
 bwr.read_buffer = (uintptr_t) readbuf;
 res = ioctl(bs- fd, BINDER_WRITE_READ,  bwr); //  读取驱动获得数据
 if (res   0) { ALOGE( binder_loop: ioctl failed (%s)\n , strerror(errno));
 break;
 }
 res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func); //  解析数据
 if (res == 0) {
 ALOGE( binder_loop: unexpected reply?!\n 
 break;
 }
 if (res   0) { ALOGE( binder_loop: io error %d %s\n , res, strerror(errno));
 break;
 }
 }
}

  binder_write 中传入了 BC_ENTER_LOOPER,看看它做的是那些事情,代码如下

int binder_write(struct binder_state *bs, void *data, size_t len)
 struct binder_write_read bwr;
 int res;
 bwr.write_size = len;
 bwr.write_consumed = 0;
 bwr.write_buffer = (uintptr_t) data;
 bwr.read_size = 0;
 bwr.read_consumed = 0;
 bwr.read_buffer = 0;
 res = ioctl(bs- fd, BINDER_WRITE_READ,  bwr);
 if (res   0) { fprintf(stderr, binder_write: ioctl failed (%s)\n ,
 strerror(errno));
 }
 return res;
}

  我们看到它先是构造了 binder_write_read 结构体,再通过 binder_ioctl 函数发送了   BINDER_WRITE_READ 指令。我们再去 binder_ioctl 函数中看看 BINDER_WRITE_READ 操作做了哪些事情。代码如下

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 int ret;
 struct binder_proc *proc = filp- private_data;
 struct binder_thread *thread;
 unsigned int size = _IOC_SIZE(cmd);
 void __user *ubuf = (void __user *)arg;
 /*printk(KERN_INFO  binder_ioctl: %d:%d %x %lx\n ,
 proc- pid, current- pid, cmd, arg);*/
 ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error   2);
 if (ret)
 return ret;
 binder_lock(__func__);
 thread = binder_get_thread(proc);
 if (thread == NULL) {
 ret = -ENOMEM;
 goto err;
 }
 switch (cmd) {
 case BINDER_WRITE_READ: {
 struct binder_write_read bwr;
 if (size != sizeof(struct binder_write_read)) {
 ret = -EINVAL;
 goto err;
 }
 if (copy_from_user( bwr, ubuf, sizeof(bwr))) {
 ret = -EFAULT;
 goto err;
 }
 binder_debug(BINDER_DEBUG_READ_WRITE,
  binder: %d:%d write %ld at %08lx, read %ld at %08lx\n ,
 proc- pid, thread- pid, bwr.write_size, bwr.write_buffer,
 bwr.read_size, bwr.read_buffer);
 if (bwr.write_size   0) { ret = binder_thread_write(proc, thread, (void __user *)bwr.write_buffer, bwr.write_size,  bwr.write_consumed);
 if (ret   0) {
 bwr.read_consumed = 0;
 if (copy_to_user(ubuf,  bwr, sizeof(bwr)))
 ret = -EFAULT;
 goto err;
 }
 }
 if (bwr.read_size   0) { ret = binder_thread_read(proc, thread, (void __user *)bwr.read_buffer, bwr.read_size,  bwr.read_consumed, filp- f_flags   O_NONBLOCK);
 if (!list_empty( proc- todo))
 wake_up_interruptible(proc- wait);
 if (ret   0) { if (copy_to_user(ubuf,  bwr, sizeof(bwr)))
 ret = -EFAULT;
 goto err;
 }
 }
 binder_debug(BINDER_DEBUG_READ_WRITE,
  binder: %d:%d wrote %ld of %ld, read return %ld of %ld\n ,
 proc- pid, thread- pid, bwr.write_consumed, bwr.write_size,
 bwr.read_consumed, bwr.read_size);
 if (copy_to_user(ubuf,  bwr, sizeof(bwr))) {
 ret = -EFAULT;
 goto err;
 }
 break;
 }
 case BINDER_SET_MAX_THREADS:
 if (copy_from_user( proc- max_threads, ubuf, sizeof(proc- max_threads))) {
 ret = -EINVAL;
 goto err;
 }
 break;
 case BINDER_SET_CONTEXT_MGR:
 if (binder_context_mgr_node != NULL) {
 printk(KERN_ERR  binder: BINDER_SET_CONTEXT_MGR already set\n 
 ret = -EBUSY;
 goto err;
 }
 ret = security_binder_set_context_mgr(proc- tsk);
 if (ret   0)
 goto err;
 if (binder_context_mgr_uid != -1) { if (binder_context_mgr_uid != current- cred- euid) {
 printk(KERN_ERR  binder: BINDER_SET_ 
  CONTEXT_MGR bad uid %d != %d\n ,
 current- cred- euid,
 binder_context_mgr_uid);
 ret = -EPERM;
 goto err;
 }
 } else
 binder_context_mgr_uid = current- cred- euid;
 binder_context_mgr_node = binder_new_node(proc, NULL, NULL);
 if (binder_context_mgr_node == NULL) {
 ret = -ENOMEM;
 goto err;
 }
 binder_context_mgr_node- local_weak_refs++;
 binder_context_mgr_node- local_strong_refs++;
 binder_context_mgr_node- has_strong_ref = 1;
 binder_context_mgr_node- has_weak_ref = 1;
 break;
 case BINDER_THREAD_EXIT:
 binder_debug(BINDER_DEBUG_THREADS,  binder: %d:%d exit\n ,
 proc- pid, thread- pid);
 binder_free_thread(proc, thread);
 thread = NULL;
 break;
 case BINDER_VERSION:
 if (size != sizeof(struct binder_version)) {
 ret = -EINVAL;
 goto err;
 }
 if (put_user(BINDER_CURRENT_PROTOCOL_VERSION,  ((struct binder_version *)ubuf)- protocol_version)) {
 ret = -EINVAL;
 goto err;
 }
 break;
 default:
 ret = -EINVAL;
 goto err;
 }
 ret = 0;
 if (thread)
 thread- looper  = ~BINDER_LOOPER_STATE_NEED_RETURN;
 binder_unlock(__func__);
 wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error   2);
 if (ret   ret != -ERESTARTSYS)
 printk(KERN_INFO  binder: %d:%d ioctl %x %lx returned %d\n , proc- pid, current- pid, cmd, arg, ret);
 return ret;
}

  我们看到先是构造了一个 binder_write_read 结构体,然后利用 copy_from_user 函数将用户态的数据拷贝至内核(驱动)中。如果有需要给线程中写入数据,便利用 binder_thread_write 写进线程中,同理,读操作也是如此。最后再将 binder_write_read 结构体写回到用户层。对于所有的读操作,数据头都是 BR_NOOP。那么对于这种数据头的处理,binder_parse 函数是直接 break,做休眠处理。

  对于 test_server 先是 binder_open,也就是 打开 binder driver,紧接着 ioctl,最后再 mmap 那一套。然后 while 循环,如果我们传入的是 lookup,他便会调用 svcmgr_lookup 获取服务;如果是 publish,它便会调用 svcmgr_publish 注册服务。

  一般情况是 test_server 先通过 binder_thread_write 函数发送 BC_TRANSACTION,接着便是调用 binder_thread_read 函数来得到一个 BR_NOOP,等待休眠。然后 service_manger 通过 binder_thread_read 获得 BR_TRANSACTION,再通过 binder_thread_write 发送一个 BC_REPLY,最后 test_server 通过 binder_thread_read 获得  BR_REPLY。

  我们重点来讲下  binder_thread_write 函数的 BC_TRANSACTION:

 1. 构造数据:

 a. 构造 binder_io;

 b. 转为  binder_transaction_data;

 c. 放入  binder_write_read 结构体中。

 2. 通过 ioctl 发送数据;

 3. 进去驱动。binder_ioctl 把数据放入 service_manger 进程的 todo 链表,并唤醒他。

 a. 根据 handle 找到目的进程 service_manger(之前 mmap 映射的空间);

 b. 把数据 copy_from_user,放入 mmap 的空间;

 c. 处理 offset 数据,flat_binder_object:构造 binder_node 给 test_server,构造 binder_ref 给 service_manger,增加引用计数。

 d. 唤醒目的进程。

  后面就一直是处于 test_server 和 service_manger 进程的 binder_thread_write 和  binder_thread_read 的来回作用中。

  在这其中所涉及的 cmd 中,只有 BC_TRANSACTION,BR_TRANSACTION,BC_REPLY 和  BR_REPLY 是涉及两进程的,其他所有的 cmd 只是 APP 和驱动的交互,用于改变 / 报告状态。

  我们来总结服务的注册过程和获取过程。

  服务注册过程如下:

 1. 构造数据,包括 name =“hello”和 flat_binder_node 结构体;

 2. 发送 ioctl;

 3. 根据 handle = 0 找到 service_manger 进程,再把数据放到 service_manger 的 todo 链表中;

 4. 构造结构体。binder_node 给源进程,binder_ref 给目的进程;

 5. 唤醒 service_manger;

 6. 调用 ADD_SERVICE 函数;

 7. 在 svclist 中创建一项(主要是 name =“hello”和 handle);

 8. binder_ref 引用服务,此时的 node 便指向 binder_node。

  上面的 1 和 2 是在 test_server 的用户态完成的,3 4 5 是在 test_server 的内核态完成的;6 7 是在 service_manger 的用户态完成的,8 是在 service_manger 的内核态完成的。

  服务获取过程如下:

 1. 构造数据(name =“hello”);

 2. 通过 ioctl 发送数据给 service_manger,handle = 0;

 3. 根据 handle = 0,找到 service_manger,把数据放入他的 todo 链表;

 4. 唤醒 service_manger;

 5. service_manger 内核态返回数据;

 6. service_manger 用户态取出数据,得到 hello 服务;

 7. 在 svclist 链表里根据 hello 服务名 找到一项,得到 handle = 1;

 8. 用 ioctl 把 handle 发给驱动;

 9. service_manger 在内核态的 refs_by_desc 树中,根据 handle = 1 找到 binder_ref,进而找到 hello 服务的 binder_node;

 10. 为 test_client 创建 binder_ref,把 handle = 1 放入 test_cient 的 todo 链表;

 11. 唤醒 tes_client;

 12. test_client 内核态返回 handle = 1;

 13. test_client 用户态得到 handle = 1,进而 binder_ref.desc = 1,它中的 node 便对应于前面的 hello 服务。

  上面的 1 2 13 是在 test_client 的用户态完成的,3 4 12 是在 test_client 的内核态完成的;6 7 8 是在 service_manger 的用户态完成的,5 9 10 11 是在 service_manger 的内核态完成的。

  下面我们来看看服务使用过程,跟注册和获取过程类似

 1. 获得“hello”服务,handle = 1;

 2. 构造数据,code 是指调用哪个函数,构造参数;

 3. 通过 ioctl 发送数据(先写后读);

 4. binder_ioctl,根据 handle 找到目的进程;即 test_server;

 5. 把数据放入 test_server 的 todo 链表;

 6. 唤醒 test_server,然后再 binder_thread_read 中休眠;

 7. test_server 内核态被唤醒,返回数据到 test_server 用户态;

 8. test_server 用户态取出数据,根据 code 和 参数 调用函数;

 9. 用返回值构造数据;

 10. 通过 ioctl 回复 REPLY;

 11. test_server 内核态找出要回复的进程,即 test_client;

 12. 把数据放入 test_client 的 todo 链表;

 13. 唤醒 test_client;

 14. 内核态被唤醒,把数据犯规给用户空间;

 15. test_client 用户态取出返回值,至此使用过程完成。

  上面的 1 2 3 15 是在 test_client 的用户态完成的,4 5 6 14 是在 test_client 的内核态完成的;8 9 10 是在
test_server 的用户态完成的,7 11 12 13 是在 test_server 的内核态完成的。

感谢你能够认真阅读完这篇文章,希望丸趣 TV 小编分享的“Android 系统中 Binder 子系统有什么用”这篇文章对大家有帮助,同时也希望大家多多支持丸趣 TV,关注丸趣 TV 行业资讯频道,更多相关知识等着你来学习!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-25发表,共计20348字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)