深入Android系统 Binder-4-驱动(2)

| BC_EXIT_LOOPER | 通知驱动,当前线程退出数据的发送和接收 |

| BC_REQUEST_DEATH_NOTYFICATION | 通知驱动接收某个Binder服务的死亡通知 |

| BC_CLEAR_DEATH_NOTYFICATION | 通知驱动不再接收某个Binder服务的死亡通知 |

| BC_DEAD_BINDER_DONE | 回应BR_DEAD_BINDER命令 |

驱动返回的命令列表

| 命令 | 说明 |

| — | — |

| BR_ERROR | 驱动内部出错了 |

| BR_OK | 命令成功 |

| BR_TRANSACTION | Binder调用命令 |

| BR_REPLY | 返回Binder调用的结果 |

| BR_ACQUIRE_RESULT | 未使用 |

| BR_DEAD_REPLY | 向驱动发送Binder调用时,如果对方已经死亡,则驱动回应此命令 |

| BR_TRANSACTION_COMPLETE | 回应BR_TRANSACTION命令 |

| BR_INCREFS | 要求增加Binder对象的弱引用计数 |

| BR_ACQUIRE | 要求增加Binder对象的强引用计数 |

| BR_DECREFS | 要求减少Binder对象的弱引用计数 |

| BR_RELEASE | 要求减少Binder对象的强引用计数 |

| BR_ATTEMPT_ACQUIRE | 要求将Binder对象的弱引用变成强引用 |

| BR_NOOP | 命令成功 |

| BR_SPAWN_LOOPER | 通知创建Binder线程 |

| BR_FINISHED | 未使用 |

| BR_DEAD_BINDER | 通知关注的Binder已经死亡 |

| BR_CLEAR_DEATH_NOTYFICATION_DONE | 回应BC_CLEAR_DEATH_NOTYFICATION |

| BR_FAILED_REPLY | 如果Binder调用函数号不正确,回复本消息 |

Binder消息序列图

前面列出的两个命令列表看上去指令蛮多的,其实可以分为四类:

  • Binder线程管理相关

  • Binder方法调用相关

  • Binder对象引用计数管理相关

  • Binder对象死亡通知相关

看下面两个序列图:

Binder调用的消息序列图:

Binder对象引用计数管理的消息序列图:

Binder驱动分析


Binder驱动中定义的操作函数如下:

static const struct file_operations binder_fops = {

.owner = THIS_MODULE,

.poll = binder_poll,

.unlocked_ioctl = binder_ioctl,

.compat_ioctl = binder_ioctl,

.mmap = binder_mmap,

.open = binder_open,

.flush = binder_flush,

.release = binder_release,

};

Binder驱动中并没有实现常用的readwrite操作。数据的传输都是通过ioctl操作来完成的。

Binder驱动中定义了很多的数据结构,一些主要的数据结构如下:

| 数据结构 | 说明 |

| — | — |

| binder_proc | 每个使用open打开Binder设备文件的进程都会在驱动中创建一个biner_proc的结构,用来记录该进程的各种信息和状态。例如:Binder节点表节点引用表等 |

| binder_thread | 每个Binder线程Binder驱动中都有一个binder_thread结构,记录线程相关的信息,例如要完成的任务等 |

| binder_node | binder_proc中有一张Binder节点对象表,表项是binder_node结构。代表进程中的BBinder对象,记录BBinder对象的指针、引用计数等数据 |

| binder_ref | binder_proc中还有一张节点引用表,表项是binder_ref结构。代表进程中的BpBinder对象,保存所引用的对象binder_node指针。BpBinder中的mHandler值,就是它在索引表中的位置 |

| binder_buffer | 驱动通过mmap的方式创建了一块大的缓存区,每次Binder传输数据,会在缓存区分配一个binder_buffer的结构来保存数据 |

在Binder驱动中,大量使用红黑树来管理数据。Binder驱动中是由内核提供的实现,具体表现是生命的一个全局变量binder_procs

static HLIST_HEAD(binder_procs);

所有进程的binder_proc结构体都将插入到这个变量代表的红黑树中。以binder_open的代码为例:

static int binder_open(struct inode *nodp, struct file *filp)

{

struct binder_proc *proc;

struct binder_device *binder_dev;

binder_debug(BINDER_DEBUG_OPEN_CLOSE, “%s: %d:%d\n”, func,

current->group_leader->pid, current->pid);

proc = kzalloc(sizeof(*proc), GFP_KERNEL);//分配空间给binder_proc结构体

//…

get_task_struct(current->group_leader);// 获取当前进程的task结构

proc->tsk = current->group_leader;

//…

INIT_LIST_HEAD(&proc->todo);// 初始化binder_porc中的todo队列

//…

filp->private_data = proc;// 将proc保存到文件结构中,供下次调用使用

mutex_lock(&binder_procs_lock);

// 将proc插入到全局变量binder_procs中

hlist_add_head(&proc->proc_node, &binder_procs);

mutex_unlock(&binder_procs_lock);

//…

return 0;

}

binder_open函数主要功能是:

  • 打开Binder驱动的设备文件

  • 为当前进程创建和初始化binder_proc结构体proc

  • 将proc插入到红黑树binder_procs

  • 将proc放入到file结构的private_data字段中

  • 调用驱动的其他操作时可以从file结构中取出代表当前进程的binder_proc

Binder的内存共享机制


前面介绍了,用户进程打开Binder设备后,会调用mmap在驱动中创建一块内存空间用于接收传递给本进程的Binder数据。我们看下mmap的代码(这部分是9.0的源码,和书中的结构有些不同):

static int binder_mmap(struct file *filp, struct vm_area_struct *vma)

{

int ret;

struct binder_proc *proc = filp->private_data;

const char *failure_string;

if (proc->tsk != current->group_leader)

return -EINVAL;

// 检查要求分配的空间是否大于SZ_4M的定义

if ((vma->vm_end - vma->vm_start) > SZ_4M)

vma->vm_end = vma->vm_start + SZ_4M;

// 检查mmap的标记,不能带有FORBIDDEN_MMAP_FLAGS

if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) {

ret = -EPERM;

failure_string = “bad vm_flags”;

goto err_bad_arg;

}

//fork 的子进程无法复制映射空间,并且不允许修改属性

vma->vm_flags |= VM_DONTCOPY | VM_MIXEDMAP;

vma->vm_flags &= ~VM_MAYWRITE;

vma->vm_ops = &binder_vm_ops;

vma->vm_private_data = proc;

// 真正内存分配的逻辑在 binder_alloc_mmap_handler中

ret = binder_alloc_mmap_handler(&proc->alloc, vma);

//…

}

int binder_alloc_mmap_handler(struct binder_alloc *alloc,

struct vm_area_struct *vma)

{

int ret;

struct vm_struct *area;

const char *failure_string;

struct binder_buffer *buffer;

mutex_lock(&binder_alloc_mmap_lock);

//如果已分配缓存区,goto 错误

if (alloc->buffer) {

ret = -EBUSY;

failure_string = “already mapped”;

goto err_already_mapped;

}

//在用户进程分配一块内存作为缓冲区

area = get_vm_area(vma->vm_end - vma->vm_start, VM_ALLOC);

//如果内存分配失败,goto 对应错误

if (area == NULL) {

ret = -ENOMEM;

failure_string = “get_vm_area”;

goto err_get_vm_area_failed;

}

//把分配的缓冲区指针放在binder_proc的buffer字段

alloc->buffer = area->addr;

//重新配置下内存起始地址和偏移量

alloc->user_buffer_offset =

vma->vm_start - (uintptr_t)alloc->buffer;

mutex_unlock(&binder_alloc_mmap_lock);

//创建物理页结构体

alloc->pages = kzalloc(sizeof(alloc->pages[0]) *

((vma->vm_end - vma->vm_start) / PAGE_SIZE),

GFP_KERNEL);

alloc->buffer_size = vma->vm_end - vma->vm_start;

//在内核分配struct buffer的内存空间

buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);

//这部分和书中着实不太一样,看的晕晕的

//目前只看出内存地址关联部分

buffer->data = alloc->buffer;

list_add(&buffer->entry, &alloc->buffers);

buffer->free = 1;

binder_insert_free_buffer(alloc, buffer);

// 异步传输将可用空间大小设置为映射大小的一半

alloc->free_async_space = alloc->buffer_size / 2;

barrier();

alloc->vma = vma;

alloc->vma_vm_mm = vma->vm_mm;

/* Same as mmgrab() in later kernel versions */

atomic_inc(&alloc->vma_vm_mm->mm_count);

return 0;

// …对应的错误信息

}

内存分配时:

  • 首先调用get_vm_area在用户进程分配一块地址空间

  • 接着在内核中也分配同样页数大小的空间

  • 然后把它们的物理内存地址绑定在一起

  • 这样应用和内核间就能共享一块空间了

当发生Binder调用时:

  • 数据会从调用进程复制到内核空间中

  • 驱动会在服务进程的缓冲区中寻找一块合适大小的空间来存放数据

  • 因为服务进程的用户空间的缓冲区和内核空间的缓冲区是共享的

  • 所以服务进程不需要将数据再从内核空间复制到用户空间

  • 节省了一次复制过程

  • 提高了Binder通信效率

驱动的ioctl操作


ioctl在驱动中的实现是binder_ioctl函数,用来处理ioctl操作的命令,这些命令最常见的就是BINDER_WRITE_READ,用于Binder调用,先看下这个命令的处理过程:

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;

// 检查binder_stop_on_user_error的值是否小于2,这个值表示Binder中的错误数

// 大于2则挂起当前进程到binder_user_error_wait的等待队列上

ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);

if (ret)

goto err_unlocked;

// 获取当前线程的数据结构

thread = binder_get_thread(proc);

if (thread == NULL) {

ret = -ENOMEM;

goto err;

}

switch (cmd) {

case BINDER_WRITE_READ:

//调用 binder_ioctl_write_read 方法

ret = binder_ioctl_write_read(filp, cmd, arg, thread);

break;

}

static int binder_ioctl_write_read(struct file *filp,

unsigned int cmd, unsigned long arg,

struct binder_thread *thread)

{

int ret = 0;

struct binder_proc *proc = filp->private_data;

unsigned int size = _IOC_SIZE(cmd);

void __user *ubuf = (void __user *)arg;

struct binder_write_read bwr;

if (size != sizeof(struct binder_write_read)) {

ret = -EINVAL;

goto out;

}

// 这里应该就是就是一次拷贝,把数据复制到内核中

if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {

ret = -EFAULT;

goto out;

}

if (bwr.write_size > 0) {

// 如果命令时传递给驱动的数据,调用 binder_thread_write 处理

ret = binder_thread_write(proc, thread,

bwr.write_buffer,

bwr.write_size,

&bwr.write_consumed);

//省略异常处理和log打印

}

if (bwr.read_size > 0) {

// 如果命令时读取驱动的数据,调用 binder_thread_read 处理

ret = binder_thread_read(proc, thread, bwr.read_buffer,

bwr.read_size,

&bwr.read_consumed,

filp->f_flags & O_NONBLOCK);

trace_binder_read_done(ret);

binder_inner_proc_lock(proc);

// 如果进程的todo队列不为空,唤醒用户进程处理

if (!binder_worklist_empty_ilocked(&proc->todo))

binder_wakeup_proc_ilocked(proc);

binder_inner_proc_unlock(proc);

//省略异常处理和log打印

}

// 异常处理

}

BINDER_WRITE_READ命令有可能是向驱动写数据,也可能是从驱动读数据

  • 写数据,通过binder_thread_write方法

  • 读数据,通过binder_thread_read方法

  • 在下一节调用过程会细讲这两个方法

除了BINDER_WRITE_READ命令外,还有像BINDER_SET_MAX_THREADS、BINDER_SET_CONTEXT_MGR等辅助通信的命令,大家可以阅读下源码。

学习的重点还是看调用过程的数据读写部分

Binder调用过程


Binder调用是Binder驱动中最核心的活动,整个过程几乎涉及了Binder驱动所有的数据结构。我们先从调用的整体流程上来看下:

  • Binder调用从客户进程中发起

  • 通过ioctl操作来运行驱动的binder_ioctl

  • 驱动接收到命令BC_TRANSACTION

  • 找到代表服务进程的binder_proc结构体

  • 在服务进程的缓冲区分配一块内存来保存从客户进程传递的数据

  • ioctl回复消息BR_TRANSACTION_COMPLETED

  • ---------到这里,本次ioctl调用结束---------

  • 客户进程收到回复消息后

  • 再次调用ioctl进入等待,准备读取数据,直到调用结果返回

服务进程无法知道何时会有Binder调用到达,因此它至少由一个线程在ioctl上等待。

  • 驱动会在有调用到达时唤醒等待的线程,并将数据传给服务进程

  • 同一时刻可能有多个Binder调用到达

  • 驱动为每个调用创建一个binder_transaction的结构体

  • 结构体中的work字段插入到服务进程的todo队列

  • todo队列是一个binder_work结构的列表

  • 每个进程都会有一个todo队列来接收需要完成的工作

  • 服务端的用户进程ioctl执行读操作时

  • 会循环执行todo队列中需要完成的任务

  • 直到队列为空才挂起等待

客户进程的调用流程

上面刚刚讲到,客户进程发送的Binder调用消息会执行到函数binder_thread_write,这个函数的功能就是处理所有用户进程发送的消息,我们看下和Binder调用有关的部分:

static int binder_thread_write(struct binder_proc *proc,

struct binder_thread *thread,

binder_uintptr_t binder_buffer, size_t size,

binder_size_t *consumed)

{

//…

case BC_TRANSACTION:

case BC_REPLY: {

struct binder_transaction_data tr;

// 包结构体tr的数据复制到内核

if (copy_from_user(&tr, ptr, sizeof(tr)))

return -EFAULT;

ptr += sizeof(tr);

// 调用 binder_transaction 函数处理

binder_transaction(proc, thread, &tr,

cmd == BC_REPLY, 0);

break;

}

//…

}

BC_TRANSACTION命令的处理就是调用了binder_transaction函数,binder_transaction函数既要处理BC_TRANSACTION也会处理BC_REPLY消息,我们先看读取的情况,也就是reply=false的情况:

  1. 找到代表目标进程的节点:

if (tr->target.handle) {

struct binder_ref *ref;

//查找handle对应的引用项

ref = binder_get_ref_olocked(proc, tr->target.handle,

true);

if (ref) {

//引用项的node字段保存了Binder对象节点的指针

//复制给target_node

target_node = binder_get_node_refs_for_txn(

ref->node, &target_proc,

&return_error);

} else {

//…

}

//…

} else {

//把管理进程的节点名放到target_node中

target_node = context->binder_context_mgr_node;

//…

}

  1. 搜寻目标线程

if (!(tr->flags & TF_ONE_WAY) && thread->transaction_stack) {

struct binder_transaction *tmp;

tmp = thread->transaction_stack;

//…

while (tmp) {

struct binder_thread *from;

spin_lock(&tmp->lock);

from = tmp->from;

if (from && from->proc == target_proc) {

atomic_inc(&from->tmp_ref);

target_thread = from;

spin_unlock(&tmp->lock);

break;

}

spin_unlock(&tmp->lock);

tmp = tmp->from_parent;

}

}

上面这段代码的逻辑是:

  • 如果本次调用不是异步调用,并且调用者线程中的transaction_stack不为NULL,则在其中查找和本次调用具有相同目标进程的transaction_stack,如果找到,则把它的目标线程设置为本次调用的目标线程。

  • transaction_stack是一个列表,保存了本线程所有正在执行的Binder调用的binder_transaction结构体。

  • Binder驱动中用binder_transaction来保存一次Binder调用的所有数据,包括传递的数据、通信双发的进程、线程信息等。因为Binder调用涉及两个进程,还要向调用端传递返回值。

  • 所以,驱动中用结构binder_transaction保存还没结束的Binder调用

  • 通常情况下执行Binder调用时不会存在相同进程的Binder调用,因此target_thread的值大多为NULL

  1. 如果有目标线程,则使用目标线程中的todo队列,否则使用目标进程的todo队列

if (target_thread)

e->to_thread = target_thread->pid;

e->to_proc = target_proc->pid;

4.为当前的Binder调用创建binder_transaction结构,并用调用的数据填充它。

t = kzalloc(sizeof(*t), GFP_KERNEL);

//…

tcomplete = kzalloc(sizeof(*tcomplete), GFP_KERNEL);

//…

if (!reply && !(tr->flags & TF_ONE_WAY))

t->from = thread;

else

t->from = NULL;

t->sender_euid = task_euid(proc->tsk);

t->to_proc = target_proc;

t->to_thread = target_thread;

t->code = tr->code;

t->flags = tr->flags;

if (!(t->flags & TF_ONE_WAY) &&

binder_supported_policy(current->policy)) {

/* Inherit supported policies for synchronous transactions */

t->priority.sched_policy = current->policy;

t->priority.prio = current->normal_prio;

} else {

/* Otherwise, fall back to the default priority */

t->priority = target_proc->default_priority;

}

5.在目标进程(也就是服务端)的缓冲区分配空间,复制用户进程的数据到内核

t->buffer = binder_alloc_new_buf(&target_proc->alloc, tr->data_size,

tr->offsets_size, extra_buffers_size,

!reply && (t->flags & TF_ONE_WAY));

//…

if (copy_from_user(t->buffer->data, (const void __user *)(uintptr_t)

tr->data.ptr.buffer, tr->data_size)) {

//…

}

if (copy_from_user(offp, (const void __user *)(uintptr_t)

tr->data.ptr.offsets, tr->offsets_size)) {

//…

}

  • 这里复制的数据是Binder调用的参数数据,也是需要传递给服务进程的数据,因此需要缓冲区。这个缓冲区是在目标进程的大的缓冲区中分配的
  1. 处理传输中的Binder对象

off_end = (void *)off_start + tr->offsets_size;

sg_bufp = (u8 *)(PTR_ALIGN(off_end, sizeof(void *)));

sg_buf_end = sg_bufp + extra_buffers_size;

off_min = 0;

for (; offp < off_end; offp++) {

//…

}

  • 通过参数传递的Binder对象需要进行转换,这里的for循环就是进行转换操作,内容较多,会在下面处理传递的Binder对象章节进行讲解
  1. 将本次调用的binder_transaction结构体链接到线程的binder_stack列表中

if (!(t->flags & TF_ONE_WAY)) {

//…

t->need_reply = 1;

t->from_parent = thread->transaction_stack;

thread->transaction_stack = t;

// 书中下面注释部分的代码已经整合到 binder_proc_transaction 函数中了

// 首先,将结构 binder_transaction中的binder_work放到目标目标进程或线程的todo队列

// 然后,创建一个新的binder_work的结构体,并将它放到发送线程的todo队列

if (!binder_proc_transaction(t, target_proc, target_thread)) {

//… 失败处理

}

}

  • binder_transaction结构中包含了一个binder_work的结构体,因此它可以被放到todo队列

  • 本地调用时binder_worktype被设置为BINDER_WORK_TRANSACTION后,插入了目标进程目标线程todo队列

  • 为了使客户进程能收到回复消息,这里也会创建一个新的binder_work的结构体,并把它的type设置成了BINDER_WORK_TRANSAXTION_COMPLETET,并将它插入到当前线程的todo队列

前面介绍过,在binder_thread_write函数执行完后,还会去判断是否需要执行binder_thread_read函数:

  • 由于调用端执行完BC_TRANSACTION后,会立刻执行ioctl的读指令

  • 所以,在调用操作上,binder_thread_read函数算是紧接着binder_thread_write函数后执行的

刚才新建的binder_work的结构体已经插入todo队列了,我们看下binder_thread_read函数会进行哪些和todo队列相关的操作:

while (1) {

//…

// 获得todo队列,获取失败则goto retry

if (!binder_worklist_empty_ilocked(&thread->todo))

list = &thread->todo;

else if (!binder_worklist_empty_ilocked(&proc->todo) &&

wait_for_proc_work)

list = &proc->todo;

else {

binder_inner_proc_unlock(proc);

/* no data added */

if (ptr - buffer == 4 && !thread->looper_need_return)

goto retry;

break;

}

//取出todo队列中的元素

w = binder_dequeue_work_head_ilocked(list);

//…

switch (w->type) {

//…省略大量case语句

case BINDER_WORK_TRANSACTION_COMPLETE: {

binder_inner_proc_unlock(proc);

cmd = BR_TRANSACTION_COMPLETE;

//把返回消息通过put_user放到用户空间的指针中

if (put_user(cmd, (uint32_t __user *)ptr))

return -EFAULT;

ptr += sizeof(uint32_t);

binder_stat_br(proc, thread, cmd);

kfree(w);

binder_stats_deleted(BINDER_STAT_TRANSACTION_COMPLETE);

} break;

//…省略大量case语句

}

//…

}

  • binder_thread_read函数所做的处理就是把回复消息BR_TRANSACTION_COMPLETE复制到用户空间

这样客户进程就可以收到回复消息了

  • 到这里,客户进程的调用结束了。但是,Binder调用才完成一半,接下来,看看服务进程是如何调用数据的。

服务进程的调用流程

服务进程至少有一个线程会在ioctl上等待调用的到来。服务进程调用ioctl时传递的是读数据的请求,所以最后调用的也是binder_thread_read函数,我们看下binder_thread_read函数完整的处理流程:

  1. 如果保存返回结果的缓冲区中还没有数据,先写入BR_NOOP消息:

if (*consumed == 0) {

if (put_user(BR_NOOP, (uint32_t __user *)ptr))

return -EFAULT;

ptr += sizeof(uint32_t);

}

  1. 进入循环处理所有todo队列中的工作

while (1) {

//…

}

  1. 读取线程或进程todo队列中需要完成的工作

struct binder_work *w = NULL;

//…

if (!binder_worklist_empty_ilocked(&thread->todo))

list = &thread->todo;

else if (!binder_worklist_empty_ilocked(&proc->todo) &&

wait_for_proc_work)

list = &proc->todo;

//…

w = binder_dequeue_work_head_ilocked(list);

  1. switch语句处理所有类型的工作

switch (w->type) {

case BINDER_WORK_TRANSACTION: {

binder_inner_proc_unlock(proc);

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

} break;

}

  • 经过客户进程的调用流程后,此时的服务进程中已经存在一个类型为BINDER_WORK_TRANSACTION的工作需要处理

  • 这里只是取出了和binder_work关联的binder_transaction结构体指针

  • 并保存到变量t

  1. 调整线程的优先级

if (!t)

continue;

if (t->buffer->target_node) {

struct binder_node *target_node = t->buffer->target_node;

struct binder_priority node_prio;

tr.target.ptr = target_node->ptr;

tr.cookie = target_node->cookie;

node_prio.sched_policy = target_node->sched_policy;

node_prio.prio = target_node->min_priority;

binder_transaction_priority(current, t, node_prio,

target_node->inherit_rt);

cmd = BR_TRANSACTION;

}

  • 这里复制的数据是Binder调用的参数数据,也是需要传递给服务进程的数据,因此需要缓冲区。这个缓冲区是在目标进程的大的缓冲区中分配的
  1. 处理传输中的Binder对象

off_end = (void *)off_start + tr->offsets_size;

sg_bufp = (u8 *)(PTR_ALIGN(off_end, sizeof(void *)));

sg_buf_end = sg_bufp + extra_buffers_size;

off_min = 0;

for (; offp < off_end; offp++) {

//…

}

  • 通过参数传递的Binder对象需要进行转换,这里的for循环就是进行转换操作,内容较多,会在下面处理传递的Binder对象章节进行讲解
  1. 将本次调用的binder_transaction结构体链接到线程的binder_stack列表中

if (!(t->flags & TF_ONE_WAY)) {

//…

t->need_reply = 1;

t->from_parent = thread->transaction_stack;

thread->transaction_stack = t;

// 书中下面注释部分的代码已经整合到 binder_proc_transaction 函数中了

// 首先,将结构 binder_transaction中的binder_work放到目标目标进程或线程的todo队列

// 然后,创建一个新的binder_work的结构体,并将它放到发送线程的todo队列

if (!binder_proc_transaction(t, target_proc, target_thread)) {

//… 失败处理

}

}

  • binder_transaction结构中包含了一个binder_work的结构体,因此它可以被放到todo队列

  • 本地调用时binder_worktype被设置为BINDER_WORK_TRANSACTION后,插入了目标进程目标线程todo队列

  • 为了使客户进程能收到回复消息,这里也会创建一个新的binder_work的结构体,并把它的type设置成了BINDER_WORK_TRANSAXTION_COMPLETET,并将它插入到当前线程的todo队列

前面介绍过,在binder_thread_write函数执行完后,还会去判断是否需要执行binder_thread_read函数:

  • 由于调用端执行完BC_TRANSACTION后,会立刻执行ioctl指令

  • 所以,在调用操作上,binder_thread_read函数算是紧接着binder_thread_write函数后执行的

刚才新建的binder_work的结构体已经插入todo队列了,我们看下binder_thread_read函数会进行哪些和todo队列相关的操作:

while (1) {

//…

// 获得todo队列,获取失败则goto retry

if (!binder_worklist_empty_ilocked(&thread->todo))

list = &thread->todo;

else if (!binder_worklist_empty_ilocked(&proc->todo) &&

wait_for_proc_work)

list = &proc->todo;

else {

binder_inner_proc_unlock(proc);

/* no data added */

if (ptr - buffer == 4 && !thread->looper_need_return)

goto retry;

break;

}

//取出todo队列中的元素

w = binder_dequeue_work_head_ilocked(list);

//…

switch (w->type) {

//…省略大量case语句

case BINDER_WORK_TRANSACTION_COMPLETE: {

binder_inner_proc_unlock(proc);

cmd = BR_TRANSACTION_COMPLETE;

//把返回消息通过put_user放到用户空间的指针中

if (put_user(cmd, (uint32_t __user *)ptr))

return -EFAULT;

ptr += sizeof(uint32_t);

binder_stat_br(proc, thread, cmd);

kfree(w);

binder_stats_deleted(BINDER_STAT_TRANSACTION_COMPLETE);

} break;

//…省略大量case语句

}

//…

}

  • binder_thread_read函数所做的处理就是把回复消息BR_TRANSACTION_COMPLETE复制到用户空间

  • 这样客户进程就可以收到回复消息了

到这里,客户进程的调用结束了。但是,Binder调用才完成一半,接下来,看看服务进程是如何调用数据的。

服务进程的调用流程

服务进程至少有一个线程会在ioctl上等待调用的到来。服务进程调用ioctl时传递的是读数据的请求,所以最后调用的也是binder_thread_read函数,我们看下binder_thread_read函数完整的处理流程:

  1. 如果保存返回结果的缓冲区中还没有数据,先写入BR_NOOP消息:

if (*consumed == 0) {

if (put_user(BR_NOOP, (uint32_t __user *)ptr))

return -EFAULT;

ptr += sizeof(uint32_t);

}

  1. 进入循环处理所有todo队列中的工作

while (1) {

//…

}

  1. 读取线程或进程todo队列中需要完成的工作

struct binder_work *w = NULL;

//…

if (!binder_worklist_empty_ilocked(&thread->todo))

list = &thread->todo;

else if (!binder_worklist_empty_ilocked(&proc->todo) &&

wait_for_proc_work)

list = &proc->todo;

//…

w = binder_dequeue_work_head_ilocked(list);

  1. switch语句处理所有类型的工作

switch (w->type) {

case BINDER_WORK_TRANSACTION: {

binder_inner_proc_unlock(proc);

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

} break;

}

  • 经过客户进程的调用流程后,此时的服务进程中已经存在一个类型为BINDER_WORK_TRANSACTION的工作需要处理

  • 这里只是取出了和binder_work关联的binder_transaction结构体指针

  • 并保存到变量t

  1. 调整线程的优先级

if (!t)

continue;

if (t->buffer->target_node) {

struct binder_node *target_node = t->buffer->target_node;

struct binder_priority node_prio;

tr.target.ptr = target_node->ptr;

tr.cookie = target_node->cookie;

node_prio.sched_policy = target_node->sched_policy;

node_prio.prio = target_node->min_priority;

binder_transaction_priority(current, t, node_prio,

target_node->inherit_rt);

cmd = BR_TRANSACTION;

}

  • 如果t为NULL,继续循环

  • 否则,开始准备返回的消息BR_TRANSACTION

  • 同时,设置线程的优先级

  • 如果调用线程的优先级低于当前线程指定的最低优先级,则把当前线程的优先级设为调用线程的优先级

  • 否则,把当前线程设为指定的最低优先级

  • 这意味着Binder线程会以尽量低的优先级运行

  1. 准备返回的数据

tr.code = t->code;

tr.flags = t->flags;

tr.sender_euid = from_kuid(current_user_ns(), t->sender_euid);

//…

// 让tr中的data指针指向内核中保存的数据缓冲区

tr.data_size = t->buffer->data_size;

tr.offsets_size = t->buffer->offsets_size;

tr.data.ptr.buffer = (binder_uintptr_t)

((uintptr_t)t->buffer->data +

binder_alloc_get_user_buffer_offset(&proc->alloc));

tr.data.ptr.offsets = tr.data.ptr.buffer +

ALIGN(t->buffer->data_size,

sizeof(void *));

// 把 BR_TRANSACTION 消息复制到用户空间

if (put_user(cmd, (uint32_t __user *)ptr)) {

//…

return -EFAULT;

}

ptr += sizeof(uint32_t);

if (copy_to_user(ptr, &tr, sizeof(tr))) {

//把结构体tr数据复制到用户空间

//…

return -EFAULT;

}

ptr += sizeof(tr);

//…

break;//跳出while循环

这一段代码都是为消息BR_TRANSACTION准备返回数据,要注意的是:

  • 调用copy_to_user复制到用户空间的只是结构体tr的数据

  • 服务进程得到这个结构体之后,会直接读取它里面的data指针的数据

  • 数据准备完毕后,使用break语句跳出while循环

  1. 启动新线程

if (proc->requested_threads == 0 &&

list_empty(&thread->proc->waiting_threads) &&

proc->requested_threads_started < proc->max_threads &&

(thread->looper & (BINDER_LOOPER_STATE_REGISTERED |

BINDER_LOOPER_STATE_ENTERED)) /* the user-space code fails to */

/*spawn a new thread if we leave this out */) {

proc->requested_threads++;

//…

if (put_user(BR_SPAWN_LOOPER, (uint32_t __user *)buffer))

return -EFAULT;

}

当前线程要执行Binder调用,新来的调用也需要线程来处理,因此:

  • 函数结束前会检查进程中可用的线程数

  • 如果需要创建新线程,则在返回的buffer数据中增加BR_SPAWN_LOOPER消息,服务进程收到这个消息会启动新的线程

完整的Binder调用过程还需要把回复消息传递给客户进程,这个过程使用的函数还是前面的这些,暂时不分析了。消化一下先

处理传递的Binder对象


前面介绍了Binder对象传递的原理和用户层的实现。(原理上整个人还是晕晕的),我们来看下Binder驱动如何实现Binder对象的传递的。

  • Binder驱动中,代表每个进程的结构binde_proc中有两个字段:nodesrefs_by_node

  • 这两个字段各指向两颗红黑树的头

  • nodes:指向的是Binder节点对象表,储存本进程中Binder实体对象相关的数据

  • refs_by_node:指向的是Binder引用对象表,存储本进程的Binder引用对象的数据以及对应的实体对象的节点指针

来个抽象点的图:

Binder驱动中处理对象转换的代码位于函数binder_transaction

case BINDER_TYPE_BINDER:

case BINDER_TYPE_WEAK_BINDER: {

struct flat_binder_object *fp;

fp = to_flat_binder_object(hdr);

ret = binder_translate_binder(fp, t, thread);

} break;

static int binder_translate_binder(struct flat_binder_object *fp,

struct binder_transaction *t,

struct binder_thread *thread)

{

struct binder_node *node;

struct binder_proc *proc = thread->proc;

struct binder_proc *target_proc = t->to_proc;

struct binder_ref_data rdata;

int ret = 0;

//根据binder值查找Binder对象表中的节点

node = binder_get_node(proc, fp->binder);

if (!node) { //没有则新建一个节点

node = binder_new_node(proc, fp);

if (!node)

return -ENOMEM;

}

//…

if (security_binder_transfer_binder(proc->tsk, target_proc->tsk)) {

ret = -EPERM;

goto done;

}

// 在接收端进程中寻找节点的引用,找不到会创建一个新的引用

ret = binder_inc_ref_for_node(target_proc, node,

fp->hdr.type == BINDER_TYPE_BINDER,

&thread->todo, &rdata);

if (ret)

goto done;

// 将传递的binder数据结构的type的值改为 BINDER_TYPE_HANDLE

if (fp->hdr.type == BINDER_TYPE_BINDER)

fp->hdr.type = BINDER_TYPE_HANDLE;

else

fp->hdr.type = BINDER_TYPE_WEAK_HANDLE;

fp->binder = 0;

// rdata.desc存放的是节点引用表中的序号,赋值给handle

fp->handle = rdata.desc;

fp->cookie = 0;

//…

}

上面的流程是

  • 通过binder_get_node函数在发送进程的Binder对象节点表中查找节点

  • 查找是通过比较数据中的binder字段和节点中对应的字段进行的

  • binder字段中存放的是Binder对象的弱引用指针

  • 如果没找到

  • 新建节点

  • binder字段cookie字段的值保存到新节点

  • 通过binder_inc_ref_for_node函数在目标进程查找Binder节点引用

  • 没找到会新建一个

  • 引用指的是节点引用表中的refs_by_node节点,包含指向Binder节点的指针

  • 把数据的type字段的值改为BINDER_TYPE_HANDLEBINDER_TYPE_WEAK_HANDLE

  • handle字段的值设为在节点引用表的序号,这也是Binder引用对象handle值的来历

下面再看看如何处理类型BINDER_TYPE_HANDLEBINDER_TYPE_WEAK_HANDLE

case BINDER_TYPE_HANDLE:

case BINDER_TYPE_WEAK_HANDLE: {

struct flat_binder_object *fp;

fp = to_flat_binder_object(hdr);

ret = binder_translate_handle(fp, t, thread);

} break;

static int binder_translate_handle(struct flat_binder_object *fp,

struct binder_transaction *t,

struct binder_thread *thread)

{

//…

// 通过handle值查找节点引用

node = binder_get_node_from_ref(proc, fp->handle,

fp->hdr.type == BINDER_TYPE_HANDLE, &src_rdata);

if (!node) {

//…

return -EINVAL;

}

//…

if (node->proc == target_proc) {

// 如果目标进程就是Binder对象的进程,开始转换

if (fp->hdr.type == BINDER_TYPE_HANDLE)

fp->hdr.type = BINDER_TYPE_BINDER;

else

fp->hdr.type = BINDER_TYPE_WEAK_BINDER;

fp->binder = node->ptr;

fp->cookie = node->cookie;

if (node->proc)

binder_inner_proc_lock(node->proc);

binder_inc_node_nilocked(node,

fp->hdr.type == BINDER_TYPE_BINDER,

0, NULL);

//…

} else {

//…

// 如果不是,则在目标进程新建一个Binder节点的引用

ret = binder_inc_ref_for_node(target_proc, node,

fp->hdr.type == BINDER_TYPE_HANDLE,

NULL, &dest_rdata);

//…

fp->handle = dest_rdata.desc;

fp->cookie = 0;

trace_binder_transaction_ref_to_ref(t, node, &src_rdata,

//…

}

}

这部分代码的流程是:

  • 通过传输数据的handle字段在发送进程的节点引用表中查找

  • 正常情况下是可以找到,不能就错误返回

  • 如果目标进程就是Binder对象所在的进程

  • 开始进行转换,把数据的type字段转为BINDER_TYPE_BINDERBINDER_TYPE_WEAK_BINDERBINDER_WORK_TRANSACTION

  • bindercookie字段设置为节点中保存的值

  • 如果目标进程不是Binder对象所在的进程

  • 在目标对象中建立一个节点对象的引用

到这里呢,Binder原理部分就差不多了,已经了解了包括:

  • 客户端调用接收消息的过程

  • 服务端监听回复消息的过

  • 驱动传输数据调度线程的操作

现在,我们再来看最后的一小部分:ServiceManager的作用

ServiceManager的作用

=================================================================================

关于ServiceManager,先简单描述:

  • ServiceManagerBinder架构中用来解析Binder名称的模块

  • ServiceManager本身就是一个Binder服务

  • ServiceManager并没有使用libbinder来构建Binder服务

  • 2020-09-04 同步了下项目代码,发现也替换成libbinder那一套了。。。。。

  • 不确定是不是更换仓储了

  • 要是这样就没意思了,简易版本对于加深binder理解还是很有帮助的

  • 我们暂且按照老的版本来看下吧

  • ServiceManager自己实现了一个简单的binder框架来直接和驱动通信。。。

ServiceManager源码路径在:frameworks/native/cmds/servicemanager,主要包含两个文件:

  • binder.c:用来实现简单的Binder通信功能

  • 简单版本的binder协议实现

  • 直接的ioctl操作与binder驱动通信

  • 不是本节的重点,感兴趣可以参照源码来学习啦

  • service_manager.c:用来实现ServiceManager的业务逻辑

  • 重点是了解ServiceManager如何响应Binder服务的注册和查询的

  • 这么重要的服务要在什么时间启动呢?

  • 这部分是在 system/core/rootdir/init.rc中配置

on post-fs

start essential services

start logd

start servicemanager

start hwservicemanager

start vndservicemanager

  • hwservicemanager 用来支持HIDL

  • vndservicemanager 第三方厂商使用,应该是从Treble架构中出现的

ServiceManager的架构
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

最后

希望大家能有一个好心态,想进什么样的公司要想清楚,并不一定是大公司,我选的也不是特大厂。当然如果你不知道选或是没有规划,那就选大公司!希望我们能先选好想去的公司再投或内推,而不是有一个公司要我我就去!还有就是不要害怕,也不要有压力,平常心对待就行,但准备要充足。最后希望大家都能拿到一份满意的 offer !如果目前有一份工作也请好好珍惜好好努力,找工作其实挺累挺辛苦的。

这里附上上述的面试题相关的几十套字节跳动,京东,小米,腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节。

由于篇幅有限,这里以图片的形式给大家展示一小部分。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

解析Binder名称的模块

  • ServiceManager本身就是一个Binder服务

  • ServiceManager并没有使用libbinder来构建Binder服务

  • 2020-09-04 同步了下项目代码,发现也替换成libbinder那一套了。。。。。

  • 不确定是不是更换仓储了

  • 要是这样就没意思了,简易版本对于加深binder理解还是很有帮助的

  • 我们暂且按照老的版本来看下吧

  • ServiceManager自己实现了一个简单的binder框架来直接和驱动通信。。。

ServiceManager源码路径在:frameworks/native/cmds/servicemanager,主要包含两个文件:

  • binder.c:用来实现简单的Binder通信功能

  • 简单版本的binder协议实现

  • 直接的ioctl操作与binder驱动通信

  • 不是本节的重点,感兴趣可以参照源码来学习啦

  • service_manager.c:用来实现ServiceManager的业务逻辑

  • 重点是了解ServiceManager如何响应Binder服务的注册和查询的

  • 这么重要的服务要在什么时间启动呢?

  • 这部分是在 system/core/rootdir/init.rc中配置

on post-fs

start essential services

start logd

start servicemanager

start hwservicemanager

start vndservicemanager

  • hwservicemanager 用来支持HIDL

  • vndservicemanager 第三方厂商使用,应该是从Treble架构中出现的

ServiceManager的架构
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

[外链图片转存中…(img-VwPHlZcC-1713678026394)]

[外链图片转存中…(img-Zqikp2xw-1713678026395)]

[外链图片转存中…(img-H06gtNRH-1713678026396)]

[外链图片转存中…(img-sTZCLGSn-1713678026397)]

[外链图片转存中…(img-YBQcOYHE-1713678026398)]

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

最后

希望大家能有一个好心态,想进什么样的公司要想清楚,并不一定是大公司,我选的也不是特大厂。当然如果你不知道选或是没有规划,那就选大公司!希望我们能先选好想去的公司再投或内推,而不是有一个公司要我我就去!还有就是不要害怕,也不要有压力,平常心对待就行,但准备要充足。最后希望大家都能拿到一份满意的 offer !如果目前有一份工作也请好好珍惜好好努力,找工作其实挺累挺辛苦的。

这里附上上述的面试题相关的几十套字节跳动,京东,小米,腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节。

由于篇幅有限,这里以图片的形式给大家展示一小部分。

[外链图片转存中…(img-0eBXr42K-1713678026400)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值