好久沒寫過部落格了，也沒怎麼研究過原始碼，偶爾看到別人的部落格都是系列研究，自愧不如啊，所以也下下來android原始碼開始看了，參考網上的講解，結合原始碼。希望這樣記錄下自己的閱讀歷程，也不枉虛度時光了。
先從android的binder驅動說起吧，以前也不懂linux驅動，有說錯的地方敬請諒解，歡迎指正。
一、驅動註冊就不詳細說了binder_init
1、初始化工作佇列binder_deferred_workqueue = create_singlethread_workqueue("binder");
2、註冊裝置misc_register(&binder_device->miscdev);
3、註冊到核心的函式
static const struct file_operations binder_fops = ;
自己的一些理解：binder_deferred_workqueue用於延時任務，以後再詳細說，其它的都好理解，雖然機制不了解，但是不影響後續分析，不再深入研究。
二、然後就是開啟binder的操作binder_open
1、分配binder_proc結構體，設定相關屬性，記錄當前程序的binder相關的資訊
2、其它一些統計資訊binder_stats_created(binder_stat_proc);記錄open的個數。
自己的一些理解：binder_dev = container_of(filp->private_data, struct binder_device,miscdev);這句一開始沒有理解，沒看到給filp->private_data賦值，怎麼就得到了binder_dev呢，原來在misc.c中misc_open中file->private_data = c;進行了賦值然後呼叫file->f_op->open(inode,file);的，因此file->private_data通misc_register(&binder_device->miscdev);指向&binder_device->miscdev,而container_of通過結構體成員的位址獲取結構體的位址因此獲取的是misc_register時傳入的&binder_device。
三、binder_ioctl，這個函式比較複雜，主要實現也是在這裡，先簡單說下自己迷惑的地方。
1、總的流程，binder_ioctl處理資料分兩種一種類似binder_set_max_threads等，直接運算元據結構，直接返回這種比較簡單，還有一種需要傳遞到相應的程序或執行緒處理。
2、先看讀取操作最終在binder_thread_read中處理
呼叫 binder_wait_for_work等待
for (;;)
}finish_wait(&thread->wait, &wait);
等待thread->wait，和執行緒相關，等待喚醒，binder_has_work_ilocked判斷等待條件 => return !binder_worklist_empty_ilocked(&thread->todo) ||
thread->looper_need_return ||
(do_proc_work &&
!binder_worklist_empty_ilocked(&thread->proc->todo)); todo佇列不為空或者looper_need_return需要返回，或者do_proc_work。
然後就是進行資料處理了，以後再詳細分析，主要根據transaction_stack查詢相對應的執行緒。
3、寫操作對於程序間操作也是寫入相應的todo佇列，後面再進行詳細的分析。
就先大概寫一下吧，整體還是比較複雜的，說的比較簡略，以後再接著寫。
核心研究 Binder框架概述
binder工作在linux層面，屬於乙個驅動，只是這個驅動不需要硬體，或者說其操作的硬體是基於一小段記憶體。從執行緒的角度來講，binder驅動 執行在核心態，客戶端程式呼叫binder是通過系統呼叫完成的。binder是一種架構，這種架構提供了服務端介面 binder驅動 客戶端介面三個模組，如...
核心研究 Binder客戶端設計
要想使用服務端，首先要獲取服務端在binder驅動中對應的mremote變數的引用。獲得該變數的引用後，就可以呼叫該變數的transact 方法。該方法的函式原型如下 public final boolean transact int code,parcel data,parcel reply,in...
binder驅動 互動時的傳輸實現 一
目錄 一 binder初始化 二 binder open binder mmap 三 binder通訊實現 3.1場景概念 3.2 transaction request 3.3 transaction async request 3.4 receive request 3.5 receive as...