淺談Service Manager成為Android進程間通信（IPC）機制Binder守護進程之路

更新時間：2016年08月29日 09:54:41 作者：羅升陽

本文主要介紹淺談Service Manager成為Android進程間通信（IPC）機制Binder守護進程之路,這里詳細(xì)介紹了相關(guān)Binder的資料，幫助大家理解學(xué)習(xí)Android 源碼Binder通信機制，有興趣的小伙伴可以參考下

上一篇文章Android進程間通信（IPC）機制Binder簡要介紹和學(xué)習(xí)計劃簡要介紹了Android系統(tǒng)進程間通信機制Binder的總體架構(gòu)，它由Client、Server、Service Manager和驅(qū)動程序Binder四個組件構(gòu)成。本文著重介紹組件Service Manager，它是整個Binder機制的守護進程，用來管理開發(fā)者創(chuàng)建的各種Server，并且向Client提供查詢Server遠(yuǎn)程接口的功能。

既然Service Manager組件是用來管理Server并且向Client提供查詢Server遠(yuǎn)程接口的功能，那么，Service Manager就必然要和Server以及Client進行通信了。我們知道，Service Manger、Client和Server三者分別是運行在獨立的進程當(dāng)中，這樣它們之間的通信也屬于進程間通信了，而且也是采用Binder機制進行進程間通信，因此，Service Manager在充當(dāng)Binder機制的守護進程的角色的同時，也在充當(dāng)Server的角色，然而，它是一種特殊的Server，下面我們將會看到它的特殊之處。

與Service Manager相關(guān)的源代碼較多，這里不會完整去分析每一行代碼，主要是帶著Service Manager是如何成為整個Binder機制中的守護進程這條主線來一步一步地深入分析相關(guān)源代碼，包括從用戶空間到內(nèi)核空間的相關(guān)源代碼。希望讀者在閱讀下面的內(nèi)容之前，先閱讀一下前一篇文章提到的兩個參考資料Android深入淺出之Binder機制和Android Binder設(shè)計與實現(xiàn)，熟悉相關(guān)概念和數(shù)據(jù)結(jié)構(gòu)，這有助于理解下面要分析的源代碼。

Service Manager在用戶空間的源代碼位于frameworks/base/cmds/servicemanager目錄下，主要是由binder.h、binder.c和service_manager.c三個文件組成。Service Manager的入口位于service_manager.c文件中的main函數(shù)：

int main(int argc, char **argv) 
{ 
 struct binder_state *bs; 
 void *svcmgr = BINDER_SERVICE_MANAGER; 
 
 bs = binder_open(128*1024); 
 
 if (binder_become_context_manager(bs)) { 
 LOGE("cannot become context manager (%s)\n", strerror(errno)); 
 return -1; 
 } 
 
 svcmgr_handle = svcmgr; 
 binder_loop(bs, svcmgr_handler); 
 return 0; 
}

main函數(shù)主要有三個功能：一是打開Binder設(shè)備文件；二是告訴Binder驅(qū)動程序自己是Binder上下文管理者，即我們前面所說的守護進程；三是進入一個無窮循環(huán)，充當(dāng)Server的角色，等待Client的請求。進入這三個功能之間，先來看一下這里用到的結(jié)構(gòu)體binder_state、宏BINDER_SERVICE_MANAGER的定義：

struct binder_state定義在frameworks/base/cmds/servicemanager/binder.c文件中：

struct binder_state 
{ 
 int fd; 
 void *mapped; 
 unsigned mapsize; 
};

fd是文件描述符，即表示打開的/dev/binder設(shè)備文件描述符；mapped是把設(shè)備文件/dev/binder映射到進程空間的起始地址；mapsize是上述內(nèi)存映射空間的大小。

宏BINDER_SERVICE_MANAGER定義frameworks/base/cmds/servicemanager/binder.h文件中：

/* the one magic object */
#define BINDER_SERVICE_MANAGER ((void*) 0)

它表示Service Manager的句柄為0。Binder通信機制使用句柄來代表遠(yuǎn)程接口，這個句柄的意義和Windows編程中用到的句柄是差不多的概念。前面說到，Service Manager在充當(dāng)守護進程的同時，它充當(dāng)Server的角色，當(dāng)它作為遠(yuǎn)程接口使用時，它的句柄值便為0，這就是它的特殊之處，其余的Server的遠(yuǎn)程接口句柄值都是一個大于0 而且由Binder驅(qū)動程序自動進行分配的。

函數(shù)首先是執(zhí)行打開Binder設(shè)備文件的操作binder_open，這個函數(shù)位于frameworks/base/cmds/servicemanager/binder.c文件中：

struct binder_state *binder_open(unsigned mapsize) 
{ 
 struct binder_state *bs; 
 
 bs = malloc(sizeof(*bs)); 
 if (!bs) { 
 errno = ENOMEM; 
 return 0; 
 } 
 
 bs->fd = open("/dev/binder", O_RDWR); 
 if (bs->fd < 0) { 
 fprintf(stderr,"binder: cannot open device (%s)\n", 
  strerror(errno)); 
 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; 
 } 
 
 /* TODO: check version */ 
 
 return bs; 
 
fail_map: 
 close(bs->fd); 
fail_open: 
 free(bs); 
 return 0; 
}

通過文件操作函數(shù)open來打開/dev/binder設(shè)備文件。設(shè)備文件/dev/binder是在Binder驅(qū)動程序模塊初始化的時候創(chuàng)建的，我們先看一下這個設(shè)備文件的創(chuàng)建過程。進入到kernel/common/drivers/staging/android目錄中，打開binder.c文件，可以看到模塊初始化入口binder_init：

static 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, 
}; 
 
static struct miscdevice binder_miscdev = { 
 .minor = MISC_DYNAMIC_MINOR, 
 .name = "binder", 
 .fops = &binder_fops 
}; 
 
static int __init binder_init(void) 
{ 
 int ret; 
 
 binder_proc_dir_entry_root = proc_mkdir("binder", NULL); 
 if (binder_proc_dir_entry_root) 
 binder_proc_dir_entry_proc = proc_mkdir("proc", binder_proc_dir_entry_root); 
 ret = misc_register(&binder_miscdev); 
 if (binder_proc_dir_entry_root) { 
 create_proc_read_entry("state", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_state, NULL); 
 create_proc_read_entry("stats", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_stats, NULL); 
 create_proc_read_entry("transactions", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_transactions, NULL); 
 create_proc_read_entry("transaction_log", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_transaction_log, &binder_transaction_log); 
 create_proc_read_entry("failed_transaction_log", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_transaction_log, &binder_transaction_log_failed); 
 } 
 return ret; 
} 
 
device_initcall(binder_init);

創(chuàng)建設(shè)備文件的地方在misc_register函數(shù)里面，關(guān)于misc設(shè)備的注冊，我們在Android日志系統(tǒng)驅(qū)動程序Logger源代碼分析一文中有提到，有興趣的讀取不訪去了解一下。其余的邏輯主要是在/proc目錄創(chuàng)建各種Binder相關(guān)的文件，供用戶訪問。從設(shè)備文件的操作方法binder_fops可以看出，前面的binder_open函數(shù)執(zhí)行語句：

bs->fd = open("/dev/binder", O_RDWR);

就進入到Binder驅(qū)動程序的binder_open函數(shù)了：

static int binder_open(struct inode *nodp, struct file *filp) 
{ 
 struct binder_proc *proc; 
 
 if (binder_debug_mask & BINDER_DEBUG_OPEN_CLOSE) 
 printk(KERN_INFO "binder_open: %d:%d\n", current->group_leader->pid, current->pid); 
 
 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); 
 mutex_lock(&binder_lock); 
 binder_stats.obj_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; 
 mutex_unlock(&binder_lock); 
 
 if (binder_proc_dir_entry_proc) { 
 char strbuf[11]; 
 snprintf(strbuf, sizeof(strbuf), "%u", proc->pid); 
 remove_proc_entry(strbuf, binder_proc_dir_entry_proc); 
 create_proc_read_entry(strbuf, S_IRUGO, binder_proc_dir_entry_proc, binder_read_proc_proc, proc); 
 } 
 
 return 0; 
}

這個函數(shù)的主要作用是創(chuàng)建一個struct binder_proc數(shù)據(jù)結(jié)構(gòu)來保存打開設(shè)備文件/dev/binder的進程的上下文信息，并且將這個進程上下文信息保存在打開文件結(jié)構(gòu)struct file的私有數(shù)據(jù)成員變量private_data中，這樣，在執(zhí)行其它文件操作時，就通過打開文件結(jié)構(gòu)struct file來取回這個進程上下文信息了。這個進程上下文信息同時還會保存在一個全局哈希表binder_procs中，驅(qū)動程序內(nèi)部使用。binder_procs定義在文件的開頭：

static HLIST_HEAD(binder_procs);

結(jié)構(gòu)體struct binder_proc也是定義在kernel/common/drivers/staging/android/binder.c文件中：

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

這個結(jié)構(gòu)體的成員比較多，這里就不一一說明了，簡單解釋一下四個成員變量threads、nodes、 refs_by_desc和refs_by_node，其它的我們在遇到的時候再詳細(xì)解釋。這四個成員變量都是表示紅黑樹的節(jié)點，也就是說，binder_proc分別掛會四個紅黑樹下。threads樹用來保存binder_proc進程內(nèi)用于處理用戶請求的線程，它的最大數(shù)量由max_threads來決定；node樹成用來保存binder_proc進程內(nèi)的Binder實體；refs_by_desc樹和refs_by_node樹用來保存binder_proc進程內(nèi)的Binder引用，即引用的其它進程的Binder實體，它分別用兩種方式來組織紅黑樹，一種是以句柄作來key值來組織，一種是以引用的實體節(jié)點的地址值作來key值來組織，它們都是表示同一樣?xùn)|西，只不過是為了內(nèi)部查找方便而用兩個紅黑樹來表示。
這樣，打開設(shè)備文件/dev/binder的操作就完成了，接著是對打開的設(shè)備文件進行內(nèi)存映射操作mmap：

bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);

對應(yīng)Binder驅(qū)動程序的binder_mmap函數(shù)：

static int binder_mmap(struct file *filp, struct vm_area_struct *vma) 
{ 
 int ret; 
 struct vm_struct *area; 
 struct binder_proc *proc = filp->private_data; 
 const char *failure_string; 
 struct binder_buffer *buffer; 
 
 if ((vma->vm_end - vma->vm_start) > SZ_4M) 
 vma->vm_end = vma->vm_start + SZ_4M; 
 
 if (binder_debug_mask & BINDER_DEBUG_OPEN_CLOSE) 
 printk(KERN_INFO 
  "binder_mmap: %d %lx-%lx (%ld K) vma %lx pagep %lx\n", 
  proc->pid, vma->vm_start, vma->vm_end, 
  (vma->vm_end - vma->vm_start) / SZ_1K, vma->vm_flags, 
  (unsigned long)pgprot_val(vma->vm_page_prot)); 
 
 if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) { 
 ret = -EPERM; 
 failure_string = "bad vm_flags"; 
 goto err_bad_arg; 
 } 
 vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE; 
 
 if (proc->buffer) { 
 ret = -EBUSY; 
 failure_string = "already mapped"; 
 goto err_already_mapped; 
 } 
 
 area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP); 
 if (area == NULL) { 
 ret = -ENOMEM; 
 failure_string = "get_vm_area"; 
 goto err_get_vm_area_failed; 
 } 
 proc->buffer = area->addr; 
 proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffer; 
 
#ifdef CONFIG_CPU_CACHE_VIPT 
 if (cache_is_vipt_aliasing()) { 
 while (CACHE_COLOUR((vma->vm_start ^ (uint32_t)proc->buffer))) { 
  printk(KERN_INFO "binder_mmap: %d %lx-%lx maps %p bad alignment\n", proc->pid, vma->vm_start, vma->vm_end, proc->buffer); 
  vma->vm_start += PAGE_SIZE; 
 } 
 } 
#endif 
 proc->pages = kzalloc(sizeof(proc->pages[0]) * ((vma->vm_end - vma->vm_start) / PAGE_SIZE), GFP_KERNEL); 
 if (proc->pages == NULL) { 
 ret = -ENOMEM; 
 failure_string = "alloc page array"; 
 goto err_alloc_pages_failed; 
 } 
 proc->buffer_size = vma->vm_end - vma->vm_start; 
 
 vma->vm_ops = &binder_vm_ops; 
 vma->vm_private_data = proc; 
 
 if (binder_update_page_range(proc, 1, proc->buffer, proc->buffer + PAGE_SIZE, vma)) { 
 ret = -ENOMEM; 
 failure_string = "alloc small buf"; 
 goto err_alloc_small_buf_failed; 
 } 
 buffer = proc->buffer; 
 INIT_LIST_HEAD(&proc->buffers); 
 list_add(&buffer->entry, &proc->buffers); 
 buffer->free = 1; 
 binder_insert_free_buffer(proc, buffer); 
 proc->free_async_space = proc->buffer_size / 2; 
 barrier(); 
 proc->files = get_files_struct(current); 
 proc->vma = vma; 
 
 /*printk(KERN_INFO "binder_mmap: %d %lx-%lx maps %p\n", proc->pid, vma->vm_start, vma->vm_end, proc->buffer);*/ 
 return 0; 
 
err_alloc_small_buf_failed: 
 kfree(proc->pages); 
 proc->pages = NULL; 
err_alloc_pages_failed: 
 vfree(proc->buffer); 
 proc->buffer = NULL; 
err_get_vm_area_failed: 
err_already_mapped: 
err_bad_arg: 
 printk(KERN_ERR "binder_mmap: %d %lx-%lx %s failed %d\n", proc->pid, vma->vm_start, vma->vm_end, failure_string, ret); 
 return ret; 
}

函數(shù)首先通過filp->private_data得到在打開設(shè)備文件/dev/binder時創(chuàng)建的struct binder_proc結(jié)構(gòu)。內(nèi)存映射信息放在vma參數(shù)中，注意，這里的vma的數(shù)據(jù)類型是struct vm_area_struct，它表示的是一塊連續(xù)的虛擬地址空間區(qū)域，在函數(shù)變量聲明的地方，我們還看到有一個類似的結(jié)構(gòu)體struct vm_struct，這個數(shù)據(jù)結(jié)構(gòu)也是表示一塊連續(xù)的虛擬地址空間區(qū)域，那么，這兩者的區(qū)別是什么呢？在Linux中，struct vm_area_struct表示的虛擬地址是給進程使用的，而struct vm_struct表示的虛擬地址是給內(nèi)核使用的，它們對應(yīng)的物理頁面都可以是不連續(xù)的。struct vm_area_struct表示的地址空間范圍是0~3G，而struct vm_struct表示的地址空間范圍是(3G + 896M + 8M) ~ 4G。struct vm_struct表示的地址空間范圍為什么不是3G~4G呢？原來，3G ~ (3G + 896M)范圍的地址是用來映射連續(xù)的物理頁面的，這個范圍的虛擬地址和對應(yīng)的實際物理地址有著簡單的對應(yīng)關(guān)系，即對應(yīng)0~896M的物理地址空間，而(3G + 896M) ~ (3G + 896M + 8M)是安全保護區(qū)域（例如，所有指向這8M地址空間的指針都是非法的），因此struct vm_struct使用(3G + 896M + 8M) ~ 4G地址空間來映射非連續(xù)的物理頁面。有關(guān)Linux的內(nèi)存管理知識，可以參考Android學(xué)習(xí)啟動篇一文提到的《Understanding the Linux Kernel》一書中的第8章。

這里為什么會同時使用進程虛擬地址空間和內(nèi)核虛擬地址空間來映射同一個物理頁面呢？這就是Binder進程間通信機制的精髓所在了，同一個物理頁面，一方映射到進程虛擬地址空間，一方面映射到內(nèi)核虛擬地址空間，這樣，進程和內(nèi)核之間就可以減少一次內(nèi)存拷貝了，提到了進程間通信效率。舉個例子如，Client要將一塊內(nèi)存數(shù)據(jù)傳遞給Server，一般的做法是，Client將這塊數(shù)據(jù)從它的進程空間拷貝到內(nèi)核空間中，然后內(nèi)核再將這個數(shù)據(jù)從內(nèi)核空間拷貝到Server的進程空間，這樣，Server就可以訪問這個數(shù)據(jù)了。但是在這種方法中，執(zhí)行了兩次內(nèi)存拷貝操作，而采用我們上面提到的方法，只需要把Client進程空間的數(shù)據(jù)拷貝一次到內(nèi)核空間，然后Server與內(nèi)核共享這個數(shù)據(jù)就可以了，整個過程只需要執(zhí)行一次內(nèi)存拷貝，提高了效率。

binder_mmap的原理講完了，這個函數(shù)的邏輯就好理解了。不過，這里還是先要解釋一下struct binder_proc結(jié)構(gòu)體的幾個成員變量。buffer成員變量是一個void*指針，它表示要映射的物理內(nèi)存在內(nèi)核空間中的起始位置；buffer_size成員變量是一個size_t類型的變量，表示要映射的內(nèi)存的大??；pages成員變量是一個struct page*類型的數(shù)組，struct page是用來描述物理頁面的數(shù)據(jù)結(jié)構(gòu)；user_buffer_offset成員變量是一個ptrdiff_t類型的變量，它表示的是內(nèi)核使用的虛擬地址與進程使用的虛擬地址之間的差值，即如果某個物理頁面在內(nèi)核空間中對應(yīng)的虛擬地址是addr的話，那么這個物理頁面在進程空間對應(yīng)的虛擬地址就為addr + user_buffer_offset。

再解釋一下Binder驅(qū)動程序管理這個內(nèi)存映射地址空間的方法，即是如何管理buffer ~ (buffer + buffer_size)這段地址空間的，這個地址空間被劃分為一段一段來管理，每一段是結(jié)構(gòu)體struct binder_buffer來描述：

struct binder_buffer { 
 struct list_head entry; /* free and allocated entries by addesss */ 
 struct rb_node rb_node; /* free entry by size or allocated entry */ 
  /* by address */ 
 unsigned free : 1; 
 unsigned allow_user_free : 1; 
 unsigned async_transaction : 1; 
 unsigned debug_id : 29; 
 
 struct binder_transaction *transaction; 
 
 struct binder_node *target_node; 
 size_t data_size; 
 size_t offsets_size; 
 uint8_t data[0]; 
};

每一個binder_buffer通過其成員entry按從低址到高地址連入到struct binder_proc中的buffers表示的鏈表中去，同時，每一個binder_buffer又分為正在使用的和空閑的，通過free成員變量來區(qū)分，空閑的binder_buffer通過成員變量rb_node連入到struct binder_proc中的free_buffers表示的紅黑樹中去，正在使用的binder_buffer通過成員變量rb_node連入到struct binder_proc中的allocated_buffers表示的紅黑樹中去。這樣做當(dāng)然是為了方便查詢和維護這塊地址空間了，這一點我們可以從其它的代碼中看到，等遇到的時候我們再分析。

終于可以回到binder_mmap這個函數(shù)來了，首先是對參數(shù)作一些健康體檢（sanity check），例如，要映射的內(nèi)存大小不能超過SIZE_4M，即4M，回到service_manager.c中的main 函數(shù)，這里傳進來的值是128 * 1024個字節(jié)，即128K，這個檢查沒有問題。通過健康體檢后，調(diào)用get_vm_area函數(shù)獲得一個空閑的vm_struct區(qū)間，并初始化proc結(jié)構(gòu)體的buffer、user_buffer_offset、pages和buffer_size和成員變量，接著調(diào)用binder_update_page_range來為虛擬地址空間proc->buffer ~ proc->buffer + PAGE_SIZE分配一個空閑的物理頁面，同時這段地址空間使用一個binder_buffer來描述，分別插入到proc->buffers鏈表和proc->free_buffers紅黑樹中去，最后，還初始化了proc結(jié)構(gòu)體的free_async_space、files和vma三個成員變量。

這里，我們繼續(xù)進入到binder_update_page_range函數(shù)中去看一下Binder驅(qū)動程序是如何實現(xiàn)把一個物理頁面同時映射到內(nèi)核空間和進程空間去的：

static int binder_update_page_range(struct binder_proc *proc, int allocate, 
 void *start, void *end, struct vm_area_struct *vma) 
{ 
 void *page_addr; 
 unsigned long user_page_addr; 
 struct vm_struct tmp_area; 
 struct page **page; 
 struct mm_struct *mm; 
 
 if (binder_debug_mask & BINDER_DEBUG_BUFFER_ALLOC) 
 printk(KERN_INFO "binder: %d: %s pages %p-%p\n", 
  proc->pid, allocate ? "allocate" : "free", start, end); 
 
 if (end <= start) 
 return 0; 
 
 if (vma) 
 mm = NULL; 
 else 
 mm = get_task_mm(proc->tsk); 
 
 if (mm) { 
 down_write(&mm->mmap_sem); 
 vma = proc->vma; 
 } 
 
 if (allocate == 0) 
 goto free_range; 
 
 if (vma == NULL) { 
 printk(KERN_ERR "binder: %d: binder_alloc_buf failed to " 
  "map pages in userspace, no vma\n", proc->pid); 
 goto err_no_vma; 
 } 
 
 for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) { 
 int ret; 
 struct page **page_array_ptr; 
 page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE]; 
 
 BUG_ON(*page); 
 *page = alloc_page(GFP_KERNEL | __GFP_ZERO); 
 if (*page == NULL) { 
  printk(KERN_ERR "binder: %d: binder_alloc_buf failed " 
   "for page at %p\n", proc->pid, page_addr); 
  goto err_alloc_page_failed; 
 } 
 tmp_area.addr = page_addr; 
 tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */; 
 page_array_ptr = page; 
 ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr); 
 if (ret) { 
  printk(KERN_ERR "binder: %d: binder_alloc_buf failed " 
   "to map page at %p in kernel\n", 
   proc->pid, page_addr); 
  goto err_map_kernel_failed; 
 } 
 user_page_addr = 
  (uintptr_t)page_addr + proc->user_buffer_offset; 
 ret = vm_insert_page(vma, user_page_addr, page[0]); 
 if (ret) { 
  printk(KERN_ERR "binder: %d: binder_alloc_buf failed " 
   "to map page at %lx in userspace\n", 
   proc->pid, user_page_addr); 
  goto err_vm_insert_page_failed; 
 } 
 /* vm_insert_page does not seem to increment the refcount */ 
 } 
 if (mm) { 
 up_write(&mm->mmap_sem); 
 mmput(mm); 
 } 
 return 0; 
 
free_range: 
 for (page_addr = end - PAGE_SIZE; page_addr >= start; 
  page_addr -= PAGE_SIZE) { 
 page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE]; 
 if (vma) 
  zap_page_range(vma, (uintptr_t)page_addr + 
  proc->user_buffer_offset, PAGE_SIZE, NULL); 
err_vm_insert_page_failed: 
 unmap_kernel_range((unsigned long)page_addr, PAGE_SIZE); 
err_map_kernel_failed: 
 __free_page(*page); 
 *page = NULL; 
err_alloc_page_failed: 
 ; 
 } 
err_no_vma: 
 if (mm) { 
 up_write(&mm->mmap_sem); 
 mmput(mm); 
 } 
 return -ENOMEM; 
}

這個函數(shù)既可以分配物理頁面，也可以用來釋放物理頁面，通過allocate參數(shù)來區(qū)別，這里我們只關(guān)注分配物理頁面的情況。要分配物理頁面的虛擬地址空間范圍為(start ~ end)，函數(shù)前面的一些檢查邏輯就不看了，直接看中間的for循環(huán)：

for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) { 
 int ret; 
 struct page **page_array_ptr; 
 page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE]; 
 
 BUG_ON(*page); 
 *page = alloc_page(GFP_KERNEL | __GFP_ZERO); 
 if (*page == NULL) { 
 printk(KERN_ERR "binder: %d: binder_alloc_buf failed " 
  "for page at %p\n", proc->pid, page_addr); 
 goto err_alloc_page_failed; 
 } 
 tmp_area.addr = page_addr; 
 tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */; 
 page_array_ptr = page; 
 ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr); 
 if (ret) { 
 printk(KERN_ERR "binder: %d: binder_alloc_buf failed " 
  "to map page at %p in kernel\n", 
  proc->pid, page_addr); 
 goto err_map_kernel_failed; 
 } 
 user_page_addr = 
 (uintptr_t)page_addr + proc->user_buffer_offset; 
 ret = vm_insert_page(vma, user_page_addr, page[0]); 
 if (ret) { 
 printk(KERN_ERR "binder: %d: binder_alloc_buf failed " 
  "to map page at %lx in userspace\n", 
  proc->pid, user_page_addr); 
 goto err_vm_insert_page_failed; 
 } 
 /* vm_insert_page does not seem to increment the refcount */ 
}

首先是調(diào)用alloc_page來分配一個物理頁面，這個函數(shù)返回一個struct page物理頁面描述符，根據(jù)這個描述的內(nèi)容初始化好struct vm_struct tmp_area結(jié)構(gòu)體，然后通過map_vm_area將這個物理頁面插入到tmp_area描述的內(nèi)核空間去，接著通過page_addr + proc->user_buffer_offset獲得進程虛擬空間地址，并通過vm_insert_page函數(shù)將這個物理頁面插入到進程地址空間去，參數(shù)vma代表了要插入的進程的地址空間。

這樣，frameworks/base/cmds/servicemanager/binder.c文件中的binder_open函數(shù)就描述完了，回到frameworks/base/cmds/servicemanager/service_manager.c文件中的main函數(shù)，下一步就是調(diào)用binder_become_context_manager來通知Binder驅(qū)動程序自己是Binder機制的上下文管理者，即守護進程。binder_become_context_manager函數(shù)位于frameworks/base/cmds/servicemanager/binder.c文件中：

          int binder_become_context_manager(struct binder_state *bs)
          {
                  return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
                }

這里通過調(diào)用ioctl文件操作函數(shù)來通知Binder驅(qū)動程序自己是守護進程，命令號是BINDER_SET_CONTEXT_MGR，沒有參數(shù)。BINDER_SET_CONTEXT_MGR定義為：

#define BINDER_SET_CONTEXT_MGR _IOW('b', 7, int)

這樣就進入到Binder驅(qū)動程序的binder_ioctl函數(shù)，我們只關(guān)注BINDER_SET_CONTEXT_MGR命令：

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; 
 
 mutex_lock(&binder_lock); 
 thread = binder_get_thread(proc); 
 if (thread == NULL) { 
 ret = -ENOMEM; 
 goto err; 
 } 
 
 switch (cmd) { 
 ...... 
 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; 
 } 
 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; 
 ...... 
 default: 
 ret = -EINVAL; 
 goto err; 
 } 
 ret = 0; 
err: 
 if (thread) 
 thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN; 
 mutex_unlock(&binder_lock); 
 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; 
}

繼續(xù)分析這個函數(shù)之前，又要解釋兩個數(shù)據(jù)結(jié)構(gòu)了，一個是struct binder_thread結(jié)構(gòu)體，顧名思久，它表示一個線程，這里就是執(zhí)行binder_become_context_manager函數(shù)的線程了。

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

proc表示這個線程所屬的進程。struct binder_proc有一個成員變量threads，它的類型是rb_root，它表示一查紅黑樹，把屬于這個進程的所有線程都組織起來，struct binder_thread的成員變量rb_node就是用來鏈入這棵紅黑樹的節(jié)點了。looper成員變量表示線程的狀態(tài)，它可以取下面這幾個值：

enum { 
 BINDER_LOOPER_STATE_REGISTERED = 0x01, 
 BINDER_LOOPER_STATE_ENTERED = 0x02, 
 BINDER_LOOPER_STATE_EXITED = 0x04, 
 BINDER_LOOPER_STATE_INVALID = 0x08, 
 BINDER_LOOPER_STATE_WAITING = 0x10, 
 BINDER_LOOPER_STATE_NEED_RETURN = 0x20 
};

其余的成員變量，transaction_stack表示線程正在處理的事務(wù)，todo表示發(fā)往該線程的數(shù)據(jù)列表，return_error和return_error2表示操作結(jié)果返回碼，wait用來阻塞線程等待某個事件的發(fā)生，stats用來保存一些統(tǒng)計信息。這些成員變量遇到的時候再分析它們的作用。

另外一個數(shù)據(jù)結(jié)構(gòu)是struct binder_node，它表示一個binder實體：

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; 
 int min_priority : 8; 
 struct list_head async_todo; 
};

rb_node和dead_node組成一個聯(lián)合體。如果這個Binder實體還在正常使用，則使用rb_node來連入proc->nodes所表示的紅黑樹的節(jié)點，這棵紅黑樹用來組織屬于這個進程的所有Binder實體；如果這個Binder實體所屬的進程已經(jīng)銷毀，而這個Binder實體又被其它進程所引用，則這個Binder實體通過dead_node進入到一個哈希表中去存放。proc成員變量就是表示這個Binder實例所屬于進程了。refs成員變量把所有引用了該Binder實體的Binder引用連接起來構(gòu)成一個鏈表。internal_strong_refs、local_weak_refs和local_strong_refs表示這個Binder實體的引用計數(shù)。ptr和cookie成員變量分別表示這個Binder實體在用戶空間的地址以及附加數(shù)據(jù)。其余的成員變量就不描述了，遇到的時候再分析。

現(xiàn)在回到binder_ioctl函數(shù)中，首先是通過filp->private_data獲得proc變量，這里binder_mmap函數(shù)是一樣的。接著通過binder_get_thread函數(shù)獲得線程信息，我們來看一下這個函數(shù)：

static struct binder_thread *binder_get_thread(struct binder_proc *proc) 
{ 
 struct binder_thread *thread = NULL; 
 struct rb_node *parent = NULL; 
 struct rb_node **p = &proc->threads.rb_node; 
 
 while (*p) { 
 parent = *p; 
 thread = rb_entry(parent, struct binder_thread, rb_node); 
 
 if (current->pid < thread->pid) 
  p = &(*p)->rb_left; 
 else if (current->pid > thread->pid) 
  p = &(*p)->rb_right; 
 else 
  break; 
 } 
 if (*p == NULL) { 
 thread = kzalloc(sizeof(*thread), GFP_KERNEL); 
 if (thread == NULL) 
  return NULL; 
 binder_stats.obj_created[BINDER_STAT_THREAD]++; 
 thread->proc = proc; 
 thread->pid = current->pid; 
 init_waitqueue_head(&thread->wait); 
 INIT_LIST_HEAD(&thread->todo); 
 rb_link_node(&thread->rb_node, parent, p); 
 rb_insert_color(&thread->rb_node, &proc->threads); 
 thread->looper |= BINDER_LOOPER_STATE_NEED_RETURN; 
 thread->return_error = BR_OK; 
 thread->return_error2 = BR_OK; 
 } 
 return thread; 
}

這里把當(dāng)前線程current的pid作為鍵值，在進程proc->threads表示的紅黑樹中進行查找，看是否已經(jīng)為當(dāng)前線程創(chuàng)建過了binder_thread信息。在這個場景下，由于當(dāng)前線程是第一次進到這里，所以肯定找不到，即*p == NULL成立，于是，就為當(dāng)前線程創(chuàng)建一個線程上下文信息結(jié)構(gòu)體binder_thread，并初始化相應(yīng)成員變量，并插入到proc->threads所表示的紅黑樹中去，下次要使用時就可以從proc中找到了。注意，這里的thread->looper = BINDER_LOOPER_STATE_NEED_RETURN。
回到binder_ioctl函數(shù)，繼續(xù)往下面，有兩個全局變量binder_context_mgr_node和binder_context_mgr_uid，它定義如下：

static struct binder_node *binder_context_mgr_node;
static uid_t binder_context_mgr_uid = -1;

binder_context_mgr_node用來表示Service Manager實體，binder_context_mgr_uid表示Service Manager守護進程的uid。在這個場景下，由于當(dāng)前線程是第一次進到這里，所以binder_context_mgr_node為NULL，binder_context_mgr_uid為-1，于是初始化binder_context_mgr_uid為current->cred->euid，這樣，當(dāng)前線程就成為Binder機制的守護進程了，并且通過binder_new_node為Service Manager創(chuàng)建Binder實體：

static struct binder_node * 
binder_new_node(struct binder_proc *proc, void __user *ptr, void __user *cookie) 
{ 
 struct rb_node **p = &proc->nodes.rb_node; 
 struct rb_node *parent = NULL; 
 struct binder_node *node; 
 
 while (*p) { 
 parent = *p; 
 node = rb_entry(parent, struct binder_node, rb_node); 
 
 if (ptr < node->ptr) 
  p = &(*p)->rb_left; 
 else if (ptr > node->ptr) 
  p = &(*p)->rb_right; 
 else 
  return NULL; 
 } 
 
 node = kzalloc(sizeof(*node), GFP_KERNEL); 
 if (node == NULL) 
 return NULL; 
 binder_stats.obj_created[BINDER_STAT_NODE]++; 
 rb_link_node(&node->rb_node, parent, p); 
 rb_insert_color(&node->rb_node, &proc->nodes); 
 node->debug_id = ++binder_last_id; 
 node->proc = proc; 
 node->ptr = ptr; 
 node->cookie = cookie; 
 node->work.type = BINDER_WORK_NODE; 
 INIT_LIST_HEAD(&node->work.entry); 
 INIT_LIST_HEAD(&node->async_todo); 
 if (binder_debug_mask & BINDER_DEBUG_INTERNAL_REFS) 
 printk(KERN_INFO "binder: %d:%d node %d u%p c%p created\n", 
  proc->pid, current->pid, node->debug_id, 
  node->ptr, node->cookie); 
 return node; 
}

注意，這里傳進來的ptr和cookie均為NULL。函數(shù)首先檢查proc->nodes紅黑樹中是否已經(jīng)存在以ptr為鍵值的node，如果已經(jīng)存在，就返回NULL。在這個場景下，由于當(dāng)前線程是第一次進入到這里，所以肯定不存在，于是就新建了一個ptr為NULL的binder_node，并且初始化其它成員變量，并插入到proc->nodes紅黑樹中去。

binder_new_node返回到binder_ioctl函數(shù)后，就把新建的binder_node指針保存在binder_context_mgr_node中了，緊接著，又初始化了binder_context_mgr_node的引用計數(shù)值。

這樣，BINDER_SET_CONTEXT_MGR命令就執(zhí)行完畢了，binder_ioctl函數(shù)返回之前，執(zhí)行了下面語句：

if (thread)
thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN;

回憶上面執(zhí)行binder_get_thread時，thread->looper = BINDER_LOOPER_STATE_NEED_RETURN，執(zhí)行了這條語句后，thread->looper = 0。

回到frameworks/base/cmds/servicemanager/service_manager.c文件中的main函數(shù)，下一步就是調(diào)用binder_loop函數(shù)進入循環(huán)，等待Client來請求了。binder_loop函數(shù)定義在frameworks/base/cmds/servicemanager/binder.c文件中：

void binder_loop(struct binder_state *bs, binder_handler func) 
{ 
 int res; 
 struct binder_write_read bwr; 
 unsigned readbuf[32]; 
 
 bwr.write_size = 0; 
 bwr.write_consumed = 0; 
 bwr.write_buffer = 0; 
 
 readbuf[0] = BC_ENTER_LOOPER; 
 binder_write(bs, readbuf, sizeof(unsigned)); 
 
 for (;;) { 
 bwr.read_size = sizeof(readbuf); 
 bwr.read_consumed = 0; 
 bwr.read_buffer = (unsigned) readbuf; 
 
 res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); 
 
 if (res < 0) { 
  LOGE("binder_loop: ioctl failed (%s)\n", strerror(errno)); 
  break; 
 } 
 
 res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func); 
 if (res == 0) { 
  LOGE("binder_loop: unexpected reply?!\n"); 
  break; 
 } 
 if (res < 0) { 
  LOGE("binder_loop: io error %d %s\n", res, strerror(errno)); 
  break; 
 } 
 } 
}

首先是通過binder_write函數(shù)執(zhí)行BC_ENTER_LOOPER命令告訴Binder驅(qū)動程序， Service Manager要進入循環(huán)了。
這里又要介紹一下設(shè)備文件/dev/binder文件操作函數(shù)ioctl的操作碼BINDER_WRITE_READ了，首先看定義：

#define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read)

這個io操作碼有一個參數(shù)，形式為struct binder_write_read：

struct binder_write_read { 
 signed long write_size; /* bytes to write */ 
 signed long write_consumed; /* bytes consumed by driver */ 
 unsigned long write_buffer; 
 signed long read_size; /* bytes to read */ 
 signed long read_consumed; /* bytes consumed by driver */ 
 unsigned long read_buffer; 
};

這里順便說一下，用戶空間程序和Binder驅(qū)動程序交互大多數(shù)都是通過BINDER_WRITE_READ命令的，write_bufffer和read_buffer所指向的數(shù)據(jù)結(jié)構(gòu)還指定了具體要執(zhí)行的操作，write_bufffer和read_buffer所指向的結(jié)構(gòu)體是struct binder_transaction_data：

struct binder_transaction_data { 
 /* The first two are only used for bcTRANSACTION and brTRANSACTION, 
 * identifying the target and contents of the transaction. 
 */ 
 union { 
 size_t handle; /* target descriptor of command transaction */ 
 void *ptr; /* target descriptor of return transaction */ 
 } target; 
 void *cookie; /* target object cookie */ 
 unsigned int code; /* transaction command */ 
 
 /* General information about the transaction. */ 
 unsigned int flags; 
 pid_t sender_pid; 
 uid_t sender_euid; 
 size_t data_size; /* number of bytes of data */ 
 size_t offsets_size; /* number of bytes of offsets */ 
 
 /* If this transaction is inline, the data immediately 
 * follows here; otherwise, it ends with a pointer to 
 * the data buffer. 
 */ 
 union { 
 struct { 
  /* transaction data */ 
  const void *buffer; 
  /* offsets from buffer to flat_binder_object structs */ 
  const void *offsets; 
 } ptr; 
 uint8_t buf[8]; 
 } data; 
};

有一個聯(lián)合體target，當(dāng)這個BINDER_WRITE_READ命令的目標(biāo)對象是本地Binder實體時，就使用ptr來表示這個對象在本進程中的地址，否則就使用handle來表示這個Binder實體的引用。只有目標(biāo)對象是Binder實體時，cookie成員變量才有意義，表示一些附加數(shù)據(jù)，由Binder實體來解釋這個個附加數(shù)據(jù)。code表示要對目標(biāo)對象請求的命令代碼，有很多請求代碼，這里就不列舉了，在這個場景中，就是BC_ENTER_LOOPER了，用來告訴Binder驅(qū)動程序， Service Manager要進入循環(huán)了。其余的請求命令代碼可以參考kernel/common/drivers/staging/android/binder.h文件中定義的兩個枚舉類型BinderDriverReturnProtocol和BinderDriverCommandProtocol。

flags成員變量表示事務(wù)標(biāo)志：

enum transaction_flags { 
 TF_ONE_WAY = 0x01, /* this is a one-way call: async, no return */ 
 TF_ROOT_OBJECT = 0x04, /* contents are the component's root object */ 
 TF_STATUS_CODE = 0x08, /* contents are a 32-bit status code */ 
 TF_ACCEPT_FDS = 0x10, /* allow replies with file descriptors */ 
};

每一個標(biāo)志位所表示的意義看注釋就行了，遇到時再具體分析。

sender_pid和sender_euid表示發(fā)送者進程的pid和euid。

data_size表示data.buffer緩沖區(qū)的大小，offsets_size表示data.offsets緩沖區(qū)的大小。這里需要解釋一下data成員變量，命令的真正要傳輸?shù)臄?shù)據(jù)就保存在data.buffer緩沖區(qū)中，前面的一成員變量都是一些用來描述數(shù)據(jù)的特征的。data.buffer所表示的緩沖區(qū)數(shù)據(jù)分為兩類，一類是普通數(shù)據(jù)，Binder驅(qū)動程序不關(guān)心，一類是Binder實體或者Binder引用，這需要Binder驅(qū)動程序介入處理。為什么呢？想想，如果一個進程A傳遞了一個Binder實體或Binder引用給進程B，那么，Binder驅(qū)動程序就需要介入維護這個Binder實體或者引用的引用計數(shù)，防止B進程還在使用這個Binder實體時，A卻銷毀這個實體，這樣的話，B進程就會crash了。所以在傳輸數(shù)據(jù)時，如果數(shù)據(jù)中含有Binder實體和Binder引和，就需要告訴Binder驅(qū)動程序它們的具體位置，以便Binder驅(qū)動程序能夠去維護它們。data.offsets的作用就在這里了，它指定在data.buffer緩沖區(qū)中，所有Binder實體或者引用的偏移位置。每一個Binder實體或者引用，通過struct flat_binder_object 來表示：

/* 
 * This is the flattened representation of a Binder object for transfer 
 * between processes. The 'offsets' supplied as part of a binder transaction 
 * contains offsets into the data where these structures occur. The Binder 
 * driver takes care of re-writing the structure type and data as it moves 
 * between processes. 
 */ 
struct flat_binder_object { 
 /* 8 bytes for large_flat_header. */ 
 unsigned long type; 
 unsigned long flags; 
 
 /* 8 bytes of data. */ 
 union { 
 void *binder; /* local object */ 
 signed long handle; /* remote object */ 
 }; 
 
 /* extra data associated with local object */ 
 void  *cookie; 
};

type表示Binder對象的類型，它取值如下所示：

enum { 
 BINDER_TYPE_BINDER = B_PACK_CHARS('s', 'b', '*', B_TYPE_LARGE), 
 BINDER_TYPE_WEAK_BINDER = B_PACK_CHARS('w', 'b', '*', B_TYPE_LARGE), 
 BINDER_TYPE_HANDLE = B_PACK_CHARS('s', 'h', '*', B_TYPE_LARGE), 
 BINDER_TYPE_WEAK_HANDLE = B_PACK_CHARS('w', 'h', '*', B_TYPE_LARGE), 
 BINDER_TYPE_FD = B_PACK_CHARS('f', 'd', '*', B_TYPE_LARGE), 
};

flags表示Binder對象的標(biāo)志，該域只對第一次傳遞Binder實體時有效，因為此刻驅(qū)動需要在內(nèi)核中創(chuàng)建相應(yīng)的實體節(jié)點，有些參數(shù)需要從該域取出。

type和flags的具體意義可以參考Android Binder設(shè)計與實現(xiàn)一文。

最后，binder表示這是一個Binder實體，handle表示這是一個Binder引用，當(dāng)這是一個Binder實體時，cookie才有意義，表示附加數(shù)據(jù)，由進程自己解釋。

數(shù)據(jù)結(jié)構(gòu)分析完了，回到binder_loop函數(shù)中，首先是執(zhí)行BC_ENTER_LOOPER命令：

readbuf[0] = BC_ENTER_LOOPER;
binder_write(bs, readbuf, sizeof(unsigned));

進入到binder_write函數(shù)中：

int binder_write(struct binder_state *bs, void *data, unsigned len) 
{ 
 struct binder_write_read bwr; 
 int res; 
 bwr.write_size = len; 
 bwr.write_consumed = 0; 
 bwr.write_buffer = (unsigned) 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變量bwr，write_size大小為4，表示write_buffer緩沖區(qū)大小為4，它的內(nèi)容是一個BC_ENTER_LOOPER命令協(xié)議號，read_buffer為空。接著又是調(diào)用ioctl函數(shù)進入到Binder驅(qū)動程序的binder_ioctl函數(shù)，這里我們也只是關(guān)注BC_ENTER_LOOPER相關(guān)的邏輯：

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; 
 
 mutex_lock(&binder_lock); 
 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; 
 } 
 if (binder_debug_mask & BINDER_DEBUG_READ_WRITE) 
  printk(KERN_INFO "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; 
  } 
 } 
 if (binder_debug_mask & BINDER_DEBUG_READ_WRITE) 
  printk(KERN_INFO "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; 
    } 
 ...... 
 default: 
 ret = -EINVAL; 
 goto err; 
 } 
 ret = 0; 
err: 
 if (thread) 
 thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN; 
 mutex_unlock(&binder_lock); 
 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; 
}

函數(shù)前面的代碼就不解釋了，同前面調(diào)用binder_become_context_manager是一樣的，只不過這里調(diào)用binder_get_thread函數(shù)獲取binder_thread，就能從proc中直接找到了，不需要創(chuàng)建一個新的。

首先是通過copy_from_user(&bwr, ubuf, sizeof(bwr))語句把用戶傳遞進來的參數(shù)轉(zhuǎn)換成struct binder_write_read結(jié)構(gòu)體，并保存在本地變量bwr中，這里可以看出bwr.write_size等于4，于是進入binder_thread_write函數(shù)，這里我們只關(guān)注BC_ENTER_LOOPER相關(guān)的代碼：

int 
binder_thread_write(struct binder_proc *proc, struct binder_thread *thread, 
   void __user *buffer, int size, signed long *consumed) 
{ 
 uint32_t cmd; 
 void __user *ptr = buffer + *consumed; 
 void __user *end = buffer + size; 
 
 while (ptr < end && thread->return_error == BR_OK) { 
 if (get_user(cmd, (uint32_t __user *)ptr)) 
  return -EFAULT; 
 ptr += sizeof(uint32_t); 
 if (_IOC_NR(cmd) < ARRAY_SIZE(binder_stats.bc)) { 
  binder_stats.bc[_IOC_NR(cmd)]++; 
  proc->stats.bc[_IOC_NR(cmd)]++; 
  thread->stats.bc[_IOC_NR(cmd)]++; 
 } 
 switch (cmd) { 
 ...... 
 case BC_ENTER_LOOPER: 
  if (binder_debug_mask & BINDER_DEBUG_THREADS) 
  printk(KERN_INFO "binder: %d:%d BC_ENTER_LOOPER\n", 
  proc->pid, thread->pid); 
  if (thread->looper & BINDER_LOOPER_STATE_REGISTERED) { 
  thread->looper |= BINDER_LOOPER_STATE_INVALID; 
  binder_user_error("binder: %d:%d ERROR:" 
   " BC_ENTER_LOOPER called after " 
   "BC_REGISTER_LOOPER\n", 
   proc->pid, thread->pid); 
  } 
  thread->looper |= BINDER_LOOPER_STATE_ENTERED; 
  break; 
 ...... 
 default: 
  printk(KERN_ERR "binder: %d:%d unknown command %d\n", proc->pid, thread->pid, cmd); 
  return -EINVAL; 
 } 
 *consumed = ptr - buffer; 
 } 
 return 0; 
}

回憶前面執(zhí)行binder_become_context_manager到binder_ioctl時，調(diào)用binder_get_thread函數(shù)創(chuàng)建的thread->looper值為0，所以這里執(zhí)行完BC_ENTER_LOOPER時，thread->looper值就變?yōu)锽INDER_LOOPER_STATE_ENTERED了，表明當(dāng)前線程進入循環(huán)狀態(tài)了。

回到binder_ioctl函數(shù)，由于bwr.read_size == 0，binder_thread_read函數(shù)就不會被執(zhí)行了，這樣，binder_ioctl的任務(wù)就完成了。

回到binder_loop函數(shù)，進入for循環(huán)：

for (;;) { 
 bwr.read_size = sizeof(readbuf); 
 bwr.read_consumed = 0; 
 bwr.read_buffer = (unsigned) readbuf; 
 
 res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); 
 
 if (res < 0) { 
 LOGE("binder_loop: ioctl failed (%s)\n", strerror(errno)); 
 break; 
 } 
 
 res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func); 
 if (res == 0) { 
 LOGE("binder_loop: unexpected reply?!\n"); 
 break; 
 } 
 if (res < 0) { 
 LOGE("binder_loop: io error %d %s\n", res, strerror(errno)); 
 break; 
 } 
}

又是執(zhí)行一個ioctl命令，注意，這里的bwr參數(shù)各個成員的值：

bwr.write_size = 0; 
bwr.write_consumed = 0; 
bwr.write_buffer = 0; 
readbuf[0] = BC_ENTER_LOOPER; 
bwr.read_size = sizeof(readbuf); 
bwr.read_consumed = 0; 
bwr.read_buffer = (unsigned) readbuf;

再次進入到binder_ioctl函數(shù)：

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; 
 
 mutex_lock(&binder_lock); 
 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; 
 } 
 if (binder_debug_mask & BINDER_DEBUG_READ_WRITE) 
  printk(KERN_INFO "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; 
  } 
 } 
 if (binder_debug_mask & BINDER_DEBUG_READ_WRITE) 
  printk(KERN_INFO "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; 
    } 
 ...... 
 default: 
 ret = -EINVAL; 
 goto err; 
 } 
 ret = 0; 
err: 
 if (thread) 
 thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN; 
 mutex_unlock(&binder_lock); 
 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; 
} 
  這次，bwr.write_size等于0，于是不會執(zhí)行binder_thread_write函數(shù)，bwr.read_size等于32，于是進入到binder_thread_read函數(shù)：
[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片
static int 
binder_thread_read(struct binder_proc *proc, struct binder_thread *thread, 
   void __user *buffer, int size, signed long *consumed, int non_block) 
{ 
 void __user *ptr = buffer + *consumed; 
 void __user *end = buffer + size; 
 
 int ret = 0; 
 int wait_for_proc_work; 
 
 if (*consumed == 0) { 
 if (put_user(BR_NOOP, (uint32_t __user *)ptr)) 
  return -EFAULT; 
 ptr += sizeof(uint32_t); 
 } 
 
retry: 
 wait_for_proc_work = thread->transaction_stack == NULL && list_empty(&thread->todo); 
 
 if (thread->return_error != BR_OK && ptr < end) { 
 if (thread->return_error2 != BR_OK) { 
  if (put_user(thread->return_error2, (uint32_t __user *)ptr)) 
  return -EFAULT; 
  ptr += sizeof(uint32_t); 
  if (ptr == end) 
  goto done; 
  thread->return_error2 = BR_OK; 
 } 
 if (put_user(thread->return_error, (uint32_t __user *)ptr)) 
  return -EFAULT; 
 ptr += sizeof(uint32_t); 
 thread->return_error = BR_OK; 
 goto done; 
 } 
 
 
 thread->looper |= BINDER_LOOPER_STATE_WAITING; 
 if (wait_for_proc_work) 
 proc->ready_threads++; 
 mutex_unlock(&binder_lock); 
 if (wait_for_proc_work) { 
 if (!(thread->looper & (BINDER_LOOPER_STATE_REGISTERED | 
  BINDER_LOOPER_STATE_ENTERED))) { 
  binder_user_error("binder: %d:%d ERROR: Thread waiting " 
   "for process work before calling BC_REGISTER_" 
   "LOOPER or BC_ENTER_LOOPER (state %x)\n", 
   proc->pid, thread->pid, thread->looper); 
  wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2); 
 } 
 binder_set_nice(proc->default_priority); 
 if (non_block) { 
  if (!binder_has_proc_work(proc, thread)) 
  ret = -EAGAIN; 
 } else 
  ret = wait_event_interruptible_exclusive(proc->wait, binder_has_proc_work(proc, thread)); 
 } else { 
 if (non_block) { 
  if (!binder_has_thread_work(thread)) 
  ret = -EAGAIN; 
 } else 
  ret = wait_event_interruptible(thread->wait, binder_has_thread_work(thread)); 
 } 
 ....... 
}

傳入的參數(shù)*consumed == 0，于是寫入一個值BR_NOOP到參數(shù)ptr指向的緩沖區(qū)中去，即用戶傳進來的bwr.read_buffer緩沖區(qū)。這時候，thread->transaction_stack == NULL，并且thread->todo列表也是空的，這表示當(dāng)前線程沒有事務(wù)需要處理，于是wait_for_proc_work為true，表示要去查看proc是否有未處理的事務(wù)。當(dāng)前thread->return_error == BR_OK，這是前面創(chuàng)建binder_thread時初始化設(shè)置的。于是繼續(xù)往下執(zhí)行，設(shè)置thread的狀態(tài)為BINDER_LOOPER_STATE_WAITING，表示線程處于等待狀態(tài)。調(diào)用binder_set_nice函數(shù)設(shè)置當(dāng)前線程的優(yōu)先級別為proc->default_priority，這是因為thread要去處理屬于proc的事務(wù)，因此要將此thread的優(yōu)先級別設(shè)置和proc一樣。在這個場景中，proc也沒有事務(wù)處理，即binder_has_proc_work(proc, thread)為false。如果文件打開模式為非阻塞模式，即non_block為true，那么函數(shù)就直接返回-EAGAIN，要求用戶重新執(zhí)行ioctl；否則的話，就通過當(dāng)前線程就通過wait_event_interruptible_exclusive函數(shù)進入休眠狀態(tài)，等待請求到來再喚醒了。

至此，我們就從源代碼一步一步地分析完Service Manager是如何成為Android進程間通信（IPC）機制Binder守護進程的了。總結(jié)一下，Service Manager是成為Android進程間通信（IPC）機制Binder守護進程的過程是這樣的：

1. 打開/dev/binder文件：open("/dev/binder", O_RDWR);

2. 建立128K內(nèi)存映射：mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);

3. 通知Binder驅(qū)動程序它是守護進程：binder_become_context_manager(bs);

4. 進入循環(huán)等待請求的到來：binder_loop(bs, svcmgr_handler);

在這個過程中，在Binder驅(qū)動程序中建立了一個struct binder_proc結(jié)構(gòu)、一個struct binder_thread結(jié)構(gòu)和一個struct binder_node結(jié)構(gòu)，這樣，Service Manager就在Android系統(tǒng)的進程間通信機制Binder擔(dān)負(fù)起守護進程的職責(zé)了。

您可能感興趣的文章: