在说明Binder之前。我们来想想Binder作为一个进程间通信的通道之前。我们常用的进程间通信有几种。
Linux中，我们常见有一下几种进程间通信：
1.pipe 管道
2.FIFO named pipe 有名管道
3.signal 信号
4.消息队列
5.socket 套子节
6.SharedMemory 共享内存
用户空间(用户态)和内核空间(内核态)
一些操作系统允许所有用户与硬件做交互。但是，类unix操作系统在用户应用程序钱把计算机物理组织相关的底层细节都隐藏起来。当程序想试用硬件资源时候，必须向操作系统发出请求。内核会对这个请求做评估，允许使用，那么内核将会代表应用与硬件交互。 为了实现这个机制，现代操作系统依赖特殊硬件特性来禁止用户程序直接与底层打交道，或者直接访问任意的物理地址。硬件为cpu引入了至少两种执行模式：用户的非特权模式和内核的特权模式。也就是我们常说的用户态和内核态。
这是来自深入理解Linux一书中的定义。举个简单的例子，当我们需要运行文件操作的时候，使用open等操作方法，就会从用户程序就会从用户态进入到内核态，当open结束之后，用户程序进入回到用户态。
为什么Linux系统要这么设计。最大的原因就是为了让内核底层透明化，同时如果用户程序出现了问题，将不会影响内核。
换我们思考一下，如果是我们，怎么在两个隔离的进程任务块中联系彼此。很常见的一个思路，我们一般能想到的是，让一个进程把需要交互的信息存到一个文件里面，另一个进程从文件中读取数据。
管道pipe
这种思路，被广泛运用到Linux系统中。比如pipe实际上是创建了两个文件（文件描述符实际上是内核缓存区），一个专门用来读，一个专门用来写。而pipe是一个半双工的通道，换句话说就是在一个时间内只能在一个单方向的进程通信。这样就可能的减少因为多个进程来回竞争文件内容，导致传输过程中出错。
而此时pipe必定是先通过内核调用copy_from_user方法把初始化数据拷贝一份内核空间中，此时通过alloc_file通过kmalloc在调用slab在内核空间创建2个文件描述符。
大致上示意图如下：
记住fd[0]是读通道，fd[1] 是写通道
FIFO named pipe
有名管道，这中管道在原来的基础上做了处理，依赖了Linux的文件系统。从名字上就能得出这种管道是先入先出的原则，能够让数据通信按照顺序来。然而有名管道更大的意义是让管道命名。原来的管道是无名管道，所以只能在自己控制下的子进程做沟通。而多了名字之后，就不需要想法子把地址交给第二个进程，而是通过名字去找文件，就能建立通道。
signal 信号
信号这个东西，我们其实早就有所耳闻。比如说我们常说的中断信号就是指的是信号的一种。而在linux内核中内置一些通知事件。每一次发出这个事件内核将会通知进程接收这些事件，并且做处理。
内核实现：
1.为了做到对应的信号能够发送到正确需要进程。内核需要记住当前进程被哪些信号阻塞。
2.当从内核态切换到用户态，检查进程是否产生信号。这种检测每个时钟都会触发一次，一般在几个毫秒内触发一次。
3.还要检测哪些信号被忽略。以下条件都满足时表示信号被忽略
- 进程没有被追踪，task_struct（用来描述进程的结构体）PT_PTRACED标示为0.
- 进程没有阻塞这种信号
- 进程忽略这种信号
4.处理信号
此时我们需要注意的是，在内核态我们是不会处理信号的，往往都会抛到用户空间，通过copy_to_user拷贝交给用户空间去处理。
消息队列
这个听起来有点像Android里面的消息队列。两者相比，设计上确实相似。消息队列的使用，先通过ftok生成一个key，再通过key用msgget创建一个消息队列(文件)。之后用msgsnd或者msgrcv发送或者接收东西。
此时在内核上实际上可以看出创建了一个文件。把对应的消息传进去消息队列中。此时读取方和写入方由于有ftok生成一个key，就能在内核空间找到对应的消息队，就能借助这个队列完成消息的传递。其中为了让数据能够来回在用户态和内核态来回切换，还是使用到了copy _from_user,copy_to_user.其数据结构是一个链表。
socket 套子节
这个我们所有人都十分的熟悉。我们做网络编程离不开它。实际上从原理上它也是一种特殊的文件，我们也是不断的监听socket的状态来回应。既然是文件操作，那么一定会经历一次用户态到内核态，内核态到用户态的转化。这种本地监听的运用，在zyogte孵化进程的时候经常用。
共享内存
共享内存的设计，是最接近binder的设计。其核心也是用过mmap内存映射技术。其设计上也和消息队列相似。也是通过ftok生成一个key，再通过这个key申请内存shmget之后，就能对这段地址做操作。
信号量
实际上信号量最主要的作用是对进程进行加锁，如果有进程访问这个正在使用的资源会进入睡眠状态。
Binder 的概述
介绍了Linux的几种基础IPC(进程间通信),我们发现一个很有趣的现象。大部分的IPC通信都通过文件作为中转站来回通讯。这样势必会造成用户态，内核态在来回切换，那么必定造成这种数据拷贝两次的情况。那么我们有没有办法处理优化这种通信方法呢？Binder就诞生了。
那么我们要设计Binder的话，又能怎么设计呢？首先为了让整个透明并且可靠化，我们能采用TCP/IP这一套思路来保证信息的可靠性。其次为了减少来回的在用户往内核中拷贝空间能够创造模仿共享内存的方式。
我们可以关注到Binder中四种角色：
Binder 驱动
ServiceManager
Binder Client
Binder Service
从这里我们明白，在内核空间中，存在这一个Binder的驱动，而这个驱动正是作为整个IPC通信的中转站。也就是类似TCP通信中的路由地位，我不在乎你究竟要是干啥，我只需要找到你，并且把消息交给你就好。
此时service manager充当的是Binder驱动的守护进程，类似于TCP通信中的DNS地位。我们会把相关的Binder注册到里面，最后会通过service manager这个服务去查找binder的远程端。而实际上这个service manager在Andrioid Binder体系中，承当了Android系统中第一个注册进入Binder的服务。
Binder Client binder的客户端，相当于C/S架构中的客户端的概念。
Binder Service binder的服务端，相当于C/S架构中中服务端的概念。
Binder驱动，本身充当一个一个类似路由表，路由分发器。每当一个client想去寻找service的时候，都会经过binder驱动，binder并不关心传输的内容是什么，只需要帮助你分发到服务。
在这里我重新申明一次，所谓的服务端和客户端的概念只是为了更加好理解，实际上在Binder驱动看来并没有所谓的服务和客户端概念，仅仅只有远程端（或者代理端）和本地端的概念。因此Binder在整个IPC进程通信中，谁发出了请求此时就是作为本地端也就是客户端，而远程响应这个请求的则是代理端/远程端，也就是上面说的服务端。
大致知道这些角色之后，也就能清楚上方这个图的意义了。很简单，在Android系统启动的时候，会去启动一个Service Manager的进程。而这个进程会初始化好内核的Binder驱动。此时DNS和路由都准备好了。只要等到服务端注册进来，客户端取链接交互即可。
下面是根据binder的设计的示意图。
为什么我说Binder和TCP十分相似。首先在我们开发中从来不会注意到binder的存在，更加不会注意到Android开发中我们居然会有信息做了跨进程通信。这也侧面说明了binder的设计优秀以及binder已经对上层来说几乎透明化。
那么让我们略去service manager 和binder 驱动看看service和client之间的关系。
实际上Binder有两种looper形式进行IPC模式。一种是AIDL，一种是添加到service manager中。
我们直接来看看service manager 服务托管的模式。接下来，我们稍微看看源码吧。
接下来我们按照顺序来聊聊，binder的启动流程时间顺序来。首先我们需要通过内核动态加载驱动，这就得益于linux的静态模块化，可以把编写一个驱动文件，在内核加载完之后，装载内核。让我们看看内核中，binder.c的源码吧。
Binder 驱动初始化
这里简单介绍一下驱动编程。驱动编程实际上和我们的Android，iOS开发还是有点相似，也是依据定义的接口来编程。
为了简单理解，我们可以把驱动看作成一种在内核加载完之后，就会加载的特殊文件。那么既然是文件，那么就一定有打开，关闭，写入等操作。
所以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,
};
复制代码
这为结构体file_operations定义下面几个方法指针，poll,ioctl,mmap,open,flush,release等。举个简单的例子，当我们调用文件描述符打开文件(调用open方法)的时候，就会通过内核空间调用用binder_open的方法。
当然，在模块加载的守护，还有一个初始化的函数。
device_initcall(binder_init);
复制代码
在驱动的时候，需要调用这个函数，而这个函数传入的binder_init这个就是对应我们的驱动初始化方法。
我们看看里面究竟有点什么东西。
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;
}
复制代码
1.首先会为binder创建一个延时的工作队列。接着就和2.3的一致了。
2.接着通过misc_register把binder注册到misc_list系统列表中
3.会为binder创建调试一个/proc/binder/proc文件夹，接着在/proc/binder目录下创建下面五个文件state,stats, transactions, transaction_log, failed_transaction_log.
这样我们就完成了binder驱动加载到了Android系统设备中。
“路由”binder驱动已经准备好了，我们再看看“DNS” service_manager.
Service Manager
首先看看init.rc中有这么一段：
start servicemanager
start hwservicemanager
start vndservicemanager
复制代码
我们再看看servicemanager.rc
service servicemanager /system/bin/servicemanager
class core animation
user system
group system readproc
critical
onrestart restart healthd
onrestart restart zygote
onrestart restart audioserver
onrestart restart media
onrestart restart surfaceflinger
onrestart restart inputflinger
onrestart restart drm
onrestart restart cameraserver
onrestart restart keystore
onrestart restart gatekeeperd
writepid /dev/cpuset/system-background/tasks
shutdown critical
复制代码
我们直接看看启动之后main方法。
int main(int argc, char** argv)
{
struct binder_state *bs;
union selinux_callback cb;
char *driver;
//没有参数，则默认打开目录下的binder
if (argc > 1) {
driver = argv[1];
} else {
driver = "/dev/binder";
}
//调用open方法
bs = binder_open(driver, 128*1024);
...
//把service_mananger设置为第一个binder服务
if (binder_become_context_manager(bs)) {
ALOGE("cannot become context manager (%s)\n", strerror(errno));
return -1;
}
...
//进入事件等待
binder_loop(bs, svcmgr_handler);
return 0;
}
复制代码
总的来说，这里涉及到了3步操作。
1.打开binder驱动
2.设置service_manager为第一个进入Binder的服务，也就是网上常说的是binder的守护进程
3.进入binder循环等待命令。
ServiceManager初始化第一步 打开binder驱动
struct binder_state *binder_open(const char* driver, size_t mapsize)
{
struct binder_state *bs;
struct binder_version vers;
bs = malloc(sizeof(*bs));
if (!bs) {
errno = ENOMEM;
return NULL;
}
bs->fd = open(driver, O_RDWR | O_CLOEXEC);
if (bs->fd < 0) {
fprintf(stderr,"binder: cannot open %s (%s)\n",
driver, strerror(errno));
goto fail_open;
}
if ((ioctl(bs->fd, BINDER_VERSION, &vers) == -1) ||
(vers.protocol_version != BINDER_CURRENT_PROTOCOL_VERSION)) {
fprintf(stderr,
"binder: kernel driver version (%d) differs from user space version (%d)\n",
vers.protocol_version, BINDER_CURRENT_PROTOCOL_VERSION);
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->fd);
fail_open:
free(bs);
return NULL;
}
复制代码
首先为binder_status创建在用户空间申请一个内存，并且打开上面传下来的binder驱动文件，返回到binder_state的fd属性中。
核心在这里
bs->fd = open(driver, O_RDWR | O_CLOEXEC);
复制代码
syscall 工作原理
用户态是怎么进入到内核态呢？这着实让人头疼。实际上open方法将会进入到内核态，而沟通内核态的方法就是sys_call方法。
这里先给出，一般来说，系统是怎么通过找到去找到内核对应的方法的。这里就涉及到了syscall的原理了。如果对c/c++编程了解的人就会明白如下当我们想要使用系统调用的时候，我们都需要这个头文件<unistd.h>。而这个头文件就是重点。
#ifndef _UAPI_ASM_ARM_UNISTD_COMMON_H
#define _UAPI_ASM_ARM_UNISTD_COMMON_H 1
#define __NR_restart_syscall (__NR_SYSCALL_BASE + 0)
#define __NR_exit (__NR_SYSCALL_BASE + 1)
#define __NR_fork (__NR_SYSCALL_BASE + 2)
#define __NR_read (__NR_SYSCALL_BASE + 3)
#define __NR_write (__NR_SYSCALL_BASE + 4)
#define __NR_open (__NR_SYSCALL_BASE + 5)
#define __NR_close (__NR_SYSCALL_BASE + 6)
#define __NR_creat (__NR_SYSCALL_BASE + 8)
#define __NR_link (__NR_SYSCALL_BASE + 9)
...
#endif
复制代码
这里面为用户空间中声明了每一个对应到内核的方法。每一次调用都会发出一个中断信号。用户空间会通过调用汇编调用，而这个汇编调用从这个头文件作为去尝试的找到来到内核中对应的方法。
因此，我们可以规划出一个syscall的流程图。就以网上最常见kill分析为例子。
从上面的图，我们可以得知，整个流程氛围以下几个步骤：
1.调用 kill()方法。
2.调用kill.S汇编方法。
3.通过汇编方法正式进入到内核态
4.从sys_call_table 查找sys_kill
5.执行真实的内核执行动作ret_fast_syscall
6.回到用户空间的kill()代码。
从这里我们可以知道整个用户空间和内核空间都有一一对应unistd.h头文件用来查找和用户空间上面一一对应的方法。而使用这个实现这个用户态往内核态转化的核心机制就是swi软中断。
所以这里有个小诀窍，每一个内核对应着用户空间调用的方法一定是xxx对应着xxx.S的汇编文件。而这个汇编文件里面有着异常常量表地址(地址名一般__NR_xxx)，而这个地址会通过调用CALL汇编指令调转到内核实际方法(实际方法名sys_xxx)。
open在用户空间的处理
#ifndef _FCNTL_H
#define _FCNTL_H
...
int openat(int __dir_fd, const char* __path, int __flags, ...);
int openat64(int __dir_fd, const char* __path, int __flags, ...) __INTRODUCED_IN(21);
int open(const char* __path, int __flags, ...);
...
#endif
复制代码
此时我们发现在open.cpp实现了这个方法
#include <fcntl.h>
#include <stdarg.h>
#include <stdlib.h>
#include <unistd.h>
#include "private/bionic_fortify.h"
//通过此处调用汇编方法
extern "C" int __openat(int, const char*, int, int);
int open(const char* pathname, int flags, ...) {
mode_t mode = 0;
if (needs_mode(flags)) {
va_list args;
va_start(args, flags);
mode = static_cast<mode_t>(va_arg(args, int));
va_end(args);
}
return __openat(AT_FDCWD, pathname, force_O_LARGEFILE(flags), mode);
}
复制代码
原来如此，在这个内核版本用__openat的异常地址来代替__open的异常地址。这种内核就减少了异常常量表的数量。我们来看看__openat.S下面的汇编。
#include <private/bionic_asm.h>
ENTRY(__openat)
mov ip, r7
.cfi_register r7, ip
//设置中断地址
ldr r7, =__NR_openat
//进入内核
swi #0
//把之前的状态从ip拿回来，进入回用户态
mov r7, ip
.cfi_restore r7
cmn r0, #(MAX_ERRNO + 1)
bxls lr
neg r0, r0
b __set_errno_internal
END(__openat)
复制代码
这里可以把汇编看成两截首先我们会把异常常量表中的地址给到r7寄存器，接着通过swi中断进入内核态，等到处理完成又进入到用户态。
open在内核空间的处理
那么我们直接奔向sys_openat。实际上我们根本找不到sys_openat的方法，但是实际上我们能够找到如下方法
SYSCALL_DEFINE4(openat, int, dfd, const char __user *, filename, int, flags,
umode_t, mode)
{
if (force_o_largefile())
flags |= O_LARGEFILE;
return do_sys_open(dfd, filename, flags, mode);
}
复制代码
而这个SYSCALL_DEFINE4是一个define实际上就是把第一个参数转化为sys_openat作为方法名。
终于来到了open了核心处理方法do_sys_open。
do_sys_open
接下来就稍微涉及到了vfs linux的虚拟文件系统。
long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
{
struct open_flags op;
int fd = build_open_flags(flags, mode, &op);
struct filename *tmp;
if (fd)
return fd;
//从进程地址读取文件路径名字
tmp = getname(filename);
if (IS_ERR(tmp))
return PTR_ERR(tmp);
//从current（进程描述符task_struct）查找对应的空闲的位置,遇到fdt不足时候扩容
fd = get_unused_fd_flags(flags);
if (fd >= 0) {
struct file *f = do_filp_open(dfd, tmp, &op);
if (IS_ERR(f)) {
put_unused_fd(fd);
fd = PTR_ERR(f);
} else {
fsnotify_open(f);
fd_install(fd, f);
}
}
putname(tmp);
return fd;
}
复制代码
1.getname 从进程地址获取路径名字
2.get_unused_fd_flags 获取一下当前fdt进程中空闲的fdt描述符，加入遇到容量不足则2倍扩容或者是（最小）PAGE_SIZE *8 。
3.当fd>= 0的时候，说明找到了空闲的位置，先通过do_filp_open获取file结构体。
4.设置fd文件描述符到file结构体中
我们主要看看do_filp_open的方法。
path_openat
而这里do_filp_open 的核心逻辑在path_openat
static struct file *path_openat(int dfd, struct filename *pathname,
struct nameidata *nd, const struct open_flags *op, int flags)
{
struct file *base = NULL;
struct file *file;
struct path path;
int opened = 0;
int error;
//从filecached获取 一个空的file
file = get_empty_filp();
if (IS_ERR(file))
return file;
file->f_flags = op->open_flag;
if (unlikely(file->f_flags & __O_TMPFILE)) {
error = do_tmpfile(dfd, pathname, nd, flags, op, file, &opened);
goto out;
}
error = path_init(dfd, pathname->name, flags | LOOKUP_PARENT, nd, &base);
if (unlikely(error))
goto out;
current->total_link_count = 0;
error = link_path_walk(pathname->name, nd);
if (unlikely(error))
goto out;
error = do_last(nd, &path, file, op, &opened, pathname);
while (unlikely(error > 0)) { /* trailing symlink */
struct path link = path;
void *cookie;
if (!(nd->flags & LOOKUP_FOLLOW)) {
path_put_conditional(&path, nd);
path_put(&nd->path);
error = -ELOOP;
break;
}
error = may_follow_link(&link, nd);
if (unlikely(error))
break;
nd->flags |= LOOKUP_PARENT;
nd->flags &= ~(LOOKUP_OPEN|LOOKUP_CREATE|LOOKUP_EXCL);
error = follow_link(&link, nd, &cookie);
if (unlikely(error))
break;
error = do_last(nd, &path, file, op, &opened, pathname);
put_link(nd, &link, cookie);
}
out:
if (nd->root.mnt && !(nd->flags & LOOKUP_ROOT))
path_put(&nd->root);
if (base)
fput(base);
if (!(opened & FILE_OPENED)) {
BUG_ON(!error);
put_filp(file);
}
if (unlikely(error)) {
if (error == -EOPENSTALE) {
if (flags & LOOKUP_RCU)
error = -ECHILD;
else
error = -ESTALE;
}
file = ERR_PTR(error);
}
return file;
}
复制代码
我们不需要过度关注细节，只需要明白binder驱动怎么贯通整个linux用户控件到内核空间的。
这里为核心，大致上分为三个步骤：
1.get_empty_filp 从 filpcache中获取一个空的file
2.path_init 设置nameidata ，这个结构体很重要一般就是代表在内核中文件路径。一般在解析和查找路径名会使用到。
3.link_path_walk 逐步解析路径，初始化dentry 结构体，这个结构体就是虚拟文件系统中的目录结构体。同时设置inode结构体。这个inode结构体在虚拟文件系统十分重要，是指索引节点。文件系统需要处理的信息都是存放到inode中，索引节点是唯一的，是随着文件的存在而存在。
4.最后交由do_last来实现虚拟文件系统启动文件.
我们重点看看do_last究竟做了什么事情，我们只关注核心逻辑
static int do_last(struct nameidata *nd, struct path *path,
struct file *file, const struct open_flags *op,
int *opened, struct filename *name)
{
...
if (!(open_flag & O_CREAT)) {
if (nd->last.name[nd->last.len])
nd->flags |= LOOKUP_FOLLOW | LOOKUP_DIRECTORY;
if (open_flag & O_PATH && !(nd->flags & LOOKUP_FOLLOW))
symlink_ok = true;
/* we _can_ be in RCU mode here */
error = lookup_fast(nd, path, &inode);
if (likely(!error))
goto finish_lookup;
if (error < 0)
goto out;
BUG_ON(nd->inode != dir->d_inode);
} else {
...
}
retry_lookup:
...
finish_lookup:
/* we _can_ be in RCU mode here */
error = -ENOENT;
if (!inode || d_is_negative(path->dentry)) {
path_to_nameidata(path, nd);
goto out;
}
if (should_follow_link(path->dentry, !symlink_ok)) {
if (nd->flags & LOOKUP_RCU) {
if (unlikely(unlazy_walk(nd, path->dentry))) {
error = -ECHILD;
goto out;
}
}
BUG_ON(inode != path->dentry->d_inode);
return 1;
}
if ((nd->flags & LOOKUP_RCU) || nd->path.mnt != path->mnt) {
path_to_nameidata(path, nd);
} else {
save_parent.dentry = nd->path.dentry;
save_parent.mnt = mntget(path->mnt);
nd->path.dentry = path->dentry;
}
nd->inode = inode;
/* Why this, you ask? _Now_ we might have grown LOOKUP_JUMPED... */
finish_open:
...
finish_open_created:
error = may_open(&nd->path, acc_mode, open_flag);
if (error)
goto out;
BUG_ON(*opened & FILE_OPENED); /* once it's opened, it's opened */
error = vfs_open(&nd->path, file, current_cred());
if (!error) {
*opened |= FILE_OPENED;
} else {
if (error == -EOPENSTALE)
goto stale_open;
goto out;
}
opened:
...
out:
if (got_write)
mnt_drop_write(nd->path.mnt);
path_put(&save_parent);
terminate_walk(nd);
return error;
exit_dput:
...
exit_fput:
...
stale_open:
...
}
复制代码
经过精简之后，假如我们想要打开一个存在的文件，将会走以下这个顺序。线调用lookup_fast来用过rcu方式(rcu是一种读写锁，允许多读入，一个线程写入)检测对应的inode是不是挂载点，是则挂在系统文件，不是继续查找知道找到为止。一旦找到了，则调到finish_lookup标签处，粗俗判断找到的文件是否是一个连接，不是则设置数据到nameidata中。接着调用mayopen检测权限，最后来到vfs_open真正的调用虚拟文件系统的启动方法。
vfs_open
vfs_open会调用do_dentry_open
static int do_dentry_open(struct file *f,
int (*open)(struct inode *, struct file *),
const struct cred *cred)
{
static const struct file_operations empty_fops = {};
struct inode *inode;
int error;
f->f_mode = OPEN_FMODE(f->f_flags) | FMODE_LSEEK |
FMODE_PREAD | FMODE_PWRITE;
path_get(&f->f_path);
inode = f->f_inode = f->f_path.dentry->d_inode;
f->f_mapping = inode->i_mapping;
....
f->f_op = fops_get(inode->i_fop);
...
if (!open)
open = f->f_op->open;
if (open) {
error = open(inode, f);
if (error)
goto cleanup_all;
}
...
复制代码
经过精简之后我们可以知道，首先先从file中获取对应的inode，而inode就是文件系统对应的索引节点，这个节点里面我们能获取file里面的操作符号。一旦判断没有打开则调用文件操作符中的open方法。
回到Binder
经过漫长的用户空间到内核空间的切换，不要忘记了，此时我们binder驱动文件。
static const struct file_operations binder_fops = {
...
.open = binder_open,
...
};
复制代码
f->f_op->open 对应的就是 binder 中binder_open 的方法指针。
binder_open
static int binder_open(struct inode *nodp, struct file *filp)
{
struct binder_proc *proc;
binder_debug(BINDER_DEBUG_OPEN_CLOSE, "binder_open: %d:%d\n",
current->group_leader->pid, current->pid);
//内核中申请binder_proc 内存
proc = kzalloc(sizeof(*proc), GFP_KERNEL);
if (proc == NULL)
return -ENOMEM;
get_task_struct(current);
proc->tsk = current;
INIT_LIST_HEAD(&proc->todo);
init_waitqueue_head(&proc->wait);
proc->default_priority = task_nice(current);
binder_lock(__func__);
binder_stats_created(BINDER_STAT_PROC);
hlist_add_head(&proc->proc_node, &binder_procs);
proc->pid = current->group_leader->pid;
INIT_LIST_HEAD(&proc->delivered_death);
filp->private_data = proc;
binder_unlock(__func__);
if (binder_debugfs_dir_entry_proc) {
char strbuf[11];
snprintf(strbuf, sizeof(strbuf), "%u", proc->pid);
proc->debugfs_entry = debugfs_create_file(strbuf, S_IRUGO,
binder_debugfs_dir_entry_proc, proc, &binder_proc_fops);
}
return 0;
}
复制代码
这里尝试的抓点细节。首先我们会遇到Binder中第一个重要的结构体binder_proc 这个结构体代表的是当前调用的binder驱动的进程对象。
struct binder_proc *proc;
binder_debug(BINDER_DEBUG_OPEN_CLOSE, "binder_open: %d:%d\n",
current->group_leader->pid, current->pid);
//内核中申请binder_proc 内存
proc = kzalloc(sizeof(*proc), GFP_KERNEL);
if (proc == NULL)
return -ENOMEM;
get_task_struct(current);
proc->tsk = current;
复制代码
kzalloc这个方法，一般是用来在内核空间申请并初始化一段内存。因此为binder_proc 是在内核中申请了内存。对linux熟悉一点的都知道，task_struct代表着进程，也就是我们常说的进程描述符。因此此时binder_proc首先记录了当前使用binder的进程节点是什么。
INIT_LIST_HEAD(&proc->todo);
init_waitqueue_head(&proc->wait);
proc->default_priority = task_nice(current);
binder_lock(__func__);
binder_stats_created(BINDER_STAT_PROC);
hlist_add_head(&proc->proc_node, &binder_procs);
proc->pid = current->group_leader->pid;
INIT_LIST_HEAD(&proc->delivered_death);
复制代码
其次我们将初始化几个binder需要的队列：
1.proc->todo binder的todo队列
2.初始化proc->wait 等待队列
3.接着把当前binder_proc中的proc_node这个双向链表，添加到静态变量binder_procs链表中。
4.binder_proc设置死亡分发列表，会在binder 发送死亡的通知中使用到。
filp->private_data = proc;
复制代码
记住此时我们把binder_proc这个对象设置为当前文件的私密数据，为后面初始化做准备。