binder驱动-------之数据结构篇1

1： 进程在binder驱动中的表示（struct binder_proc）

每个参与binder通讯的进程在binder驱动中，都会用这样一个结构体来描述。在应用空间，每个进程都会通过ProcessState::self（）函数来调用到open_driver（）函数，从而open一次/dev/binder节点，并且会创建一个属于该进程的一个 binder_proc *proc 结构体，并初始化该结构体，最后添加到全局的 binder_procs 哈希列表中。

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;
};

1.1 binder misc

• proc_node成员：用于将当前系统所有参与binde通讯的进程通过该节点组织到一张hash表：binder_procs中
• threads：该成员的描述见下节。
• nodes： 属于该进程的所有binder实体都连接在以该节点为根的红黑树下
• refs_by_desc：属于该进程的所有binder引用以引用号为索引，组织在以该节点为根的红黑树下
• refs_by_node：属于该进程的所有binder引用以该引用对应的binder实体在内核的地址为索引，组织在以该节点为根的红黑树下

为什么binder引用要组织成两颗红黑树呢，前一颗树便于在已知引用号（handle）的情况下快速得到binder引用（struct binder_ref），而后者便于在已知binder实体（struct binder_node）的地址，快速得到该binder实体在进程下的binder引用（struct binder_ref），典型的以内存换速度，在ipc通讯中，速度是至关重要的。

• pid：当前进程的id号

1.2 binder内存管理相关

binder驱动为每个参与通讯的进程开辟了1Mbyte左右的内存区域，他们是虚拟地址连续，但是物理地址可能不连续。到这里具有忧患意识的程序员可能已经意识到：如果系统很有多进程都参与binder通讯，每个进程都有1M左右的内存空间，那这个系统内存不是一下就用光光了？呵呵，但事实是这样的：binder驱动只是预留了一段1M大小的虚拟地址，只是做了一个物理页的内存映射，其他都空着，虚位以待，待日后需要实际访问时，再去根据需要分配实际的物理内存；并且在使用完后都会及时释放掉，这样就充分利用了宝贵的物理内存。先上一个大概的草图：

• vma：当前进程的mmap对应的内存区块在应用空间的表示