国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

android servicemanager與binder源碼分析二(暫時作廢,后面會重新整理)

Ocean / 688人閱讀

摘要:抱歉,此文暫時作廢,不會使用的刪除功能。我會在后面重新整理后再繼續寫下去。是內部的一個機制,通過設備驅動的協助能夠起到進程間通訊的的作用。這個應該是個全局表,統計所有結構。實際上是保存在打開的設備文件的結構中。目前還未涉及到其他操作,只是。

抱歉,此文暫時作廢,不會使用segmentfault的刪除功能。我會在后面重新整理后再繼續寫下去。

繼續上篇的文,這篇打算進入到android的內核世界,真正接觸到binder。
binder是android內部的一個機制,通過設備驅動的協助能夠起到進程間通訊的(ipc)的作用。那么binder的設備驅動的源碼在/drivers/staging/android/binder.c這個路徑下。
先看下定義:

3632static const struct file_operations binder_fops = {
3633    .owner = THIS_MODULE,
3634    .poll = binder_poll,
3635    .unlocked_ioctl = binder_ioctl,
3636    .compat_ioctl = binder_ioctl,
3637    .mmap = binder_mmap,
3638    .open = binder_open,
3639    .flush = binder_flush,
3640    .release = binder_release,
3641};

這里說明了設備的各項操作對應的函數。
設備驅動是在系統剛開始的時候就初始化好的,初始化的過程看binder_init,不是重點,因此不在這里累述。這個初始化的過程如果進入的以及怎么發展的,有機會再其他文中敘述吧。
上文的servicemanager的main函數中首先就是open設備,因此先從open開始:

2941static int binder_open(struct inode *nodp, struct file *filp)
2942{
2943    struct binder_proc *proc;
2944
2945    binder_debug(BINDER_DEBUG_OPEN_CLOSE, "binder_open: %d:%d
",
2946             current->group_leader->pid, current->pid);
2947
2948    proc = kzalloc(sizeof(*proc), GFP_KERNEL);
2949    if (proc == NULL)
2950        return -ENOMEM;
2951    get_task_struct(current);
2952    proc->tsk = current;
2953    INIT_LIST_HEAD(&proc->todo);
2954    init_waitqueue_head(&proc->wait);
2955    proc->default_priority = task_nice(current);
2956
2957    binder_lock(__func__);
2958
2959    binder_stats_created(BINDER_STAT_PROC);
2960    hlist_add_head(&proc->proc_node, &binder_procs);
2961    proc->pid = current->group_leader->pid;
2962    INIT_LIST_HEAD(&proc->delivered_death);
2963    filp->private_data = proc;
2964
2965    binder_unlock(__func__);
2966
2967    if (binder_debugfs_dir_entry_proc) {
2968        char strbuf[11];
2969
2970        snprintf(strbuf, sizeof(strbuf), "%u", proc->pid);
2971        proc->debugfs_entry = debugfs_create_file(strbuf, S_IRUGO,
2972            binder_debugfs_dir_entry_proc, proc, &binder_proc_fops);
2973    }
2974
2975    return 0;
2976}

1.創建binder_proc結構;
2.各種維護性的鏈表及結構的添加;
3.存儲proc到私有數據內;

先說下,內核開空間都是使用kzalloc與應用層的malloc類似。
這里用到一個current結構,是linux的一個指針,指向當前正在運行的進程結構task_struct,這里還是先不深究,大體意思了解不影響后續即可。后面就是INIT_LIST_HEAD(&proc->todo);初始化鏈表頭,這個鏈表是怎么回事兒呢?先看下proc的結構吧:

292struct binder_proc {
293    struct hlist_node proc_node;
294    struct rb_root threads;
295    struct rb_root nodes;
296    struct rb_root refs_by_desc;
297    struct rb_root refs_by_node;
298    int pid;
299    struct vm_area_struct *vma;
300    struct mm_struct *vma_vm_mm;
301    struct task_struct *tsk;
302    struct files_struct *files;
303    struct hlist_node deferred_work_node;
304    int deferred_work;
305    void *buffer;
306    ptrdiff_t user_buffer_offset;
307
308    struct list_head buffers;
309    struct rb_root free_buffers;
310    struct rb_root allocated_buffers;
311    size_t free_async_space;
312
313    struct page **pages;
314    size_t buffer_size;
315    uint32_t buffer_free;
316    struct list_head todo;
317    wait_queue_head_t wait;
318    struct binder_stats stats;
319    struct list_head delivered_death;
320    int max_threads;
321    int requested_threads;
322    int requested_threads_started;
323    int ready_threads;
324    long default_priority;
325    struct dentry *debugfs_entry;
326};

這個結構的寫法很c很linux,可以看到可能會有很多個proc結構被貫穿成為一個鏈表統一管理,那么結合之前的內容猜測,binder_proc結構可以支持多個每個對應一個進程,然后通過鏈表來維護,那么進一步思考,本身binder就是為了支持跨進程通訊的,那么這些通訊之間的binder銜接就是在這個鏈表結構中維護。
下面,init_waitqueue_head(&proc->wait);初始化linux的等待隊列。又是個宏,內容如下:

71#define init_waitqueue_head(q)                
72    do {                        
73        static struct lock_class_key __key;    
74                            
75        __init_waitqueue_head((q), #q, &__key);    
76    } while (0)
77
78#ifdef CONFIG_LOCKDEP
79# define __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) 
80    ({ init_waitqueue_head(&name); name; })
81# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) 
82    wait_queue_head_t name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
83#else
84# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) DECLARE_WAIT_QUEUE_HEAD(name)
85#endif
86

帶入的參數是proc結構中的一個成員wait,感覺這里也是個隊列(鏈表),用來維護等待處理的binder_proc結構。那么大膽猜測下,系統利用這個來建立等待通訊處理的binder進程隊列,可在這基礎上進行各種策略調配來管理binder通訊的過程,不能放著驅動自我的承載力來決定(可能帶來穩定性隱患)。
再往后看,proc->default_priority = task_nice(current); 記錄當前進程的優先級。看吧,之前的策略這里就會體現。
然后hlist_add_head(&proc->proc_node, &binder_procs);又一個,真linux真c,不得不說:看系統源碼就必須習慣各種鏈表的這種方式,其實很好,不用額外維護什么東西,這種原始的方式其實有時候是最適合的,所以說,機制不是多復雜就牛逼的,而是看是否符合當前的體系當前的場景。這個應該是個全局hash表,統計所有binder_proc結構。

借用一張網絡上的圖說明下proc結構:

最后保存這個proc倒private_data里,這個私有數據中。然后完了。
再回顧一下吧,每次打開設備就創建一個binder_proc結構,并將當前進程的信息保存在這里,然后將其掛接在系統的各個鏈表或紅黑樹或hash表中,為了便于日后的策略和維護。之后再將這個proc結構保留到私有數據中。實際上是保存在打開的設備文件的結構中。目前還未涉及到其他操作,只是binder_open。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/65002.html

相關文章

  • android servicemanagerbinder源碼分析一 ------ native層的

    摘要:以版本源碼為例。源碼位于下打開驅動設備,將自己作為的管理者,進入循環,作為等待的請求位于首先,建立一個結構體,然后剩下的就是給這個結構體的成員賦值。同屬于這一層,因此我們看看具體內容剛才從驅動設備讀取的的前位取出來作為進行判斷處理。 前一陣子在忙項目,沒什么更新,這次開始寫點android源碼內部的東西分析下。以6.0.1_r10版本android源碼為例。servicemanager...

    馬忠志 評論0 收藏0
  • android servicemanagerbinder源碼分析 ------ servicem

    摘要:也同時可以看到責任鏈的應用,一個請求從上到下會經過很多層,每層都只處理和自己相關的部分,如果沒有則交由下層繼續傳遞,如果有直接返回。因此雖然看著費勁點,但是在此還是要對搞操作系統的以及研究操作系統的人們給予敬意。 承接上篇,serviceManager是怎么被調用的呢?如何為app提供服務支持?怎么銜接的?。這次我打算從最上層開始逐步把脈絡屢清楚。首先,我們在寫app的時候需要使用Au...

    Anleb 評論0 收藏0
  • android servicemanagerbinder源碼分析三------如何進入內核通訊

    摘要:的構造傳遞進入的就是。如果狀態是,直接返回。到底是否正確呢看代碼先創建一個對象,這個對象是個存儲讀寫內容的對象。然后終于進入了內核驅動的部分。 承接上文,從getService開始,要開始走binder的通訊機制了。首先是上文的java層 /frameworks/base/core/java/android/os/ServiceManagerNative.java: 118 pu...

    lijy91 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<