struct binder_node的示例分析

這篇文章主要介紹struct binder_node的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

struct binder_node {            
    int debug_id;               // 幫助調(diào)試用的

    // 當(dāng)Binder實(shí)體對(duì)象的引用計(jì)數(shù)由0變?yōu)?或由1變?yōu)?時(shí)，Binder驅(qū)動(dòng)程序就會(huì)請求相應(yīng)的
    // Service組件增加或減少其引用計(jì)數(shù)。Binder驅(qū)動(dòng)程序就會(huì)將“該引用計(jì)數(shù)修改”封裝成一個(gè)類
    // 型為一個(gè)類型為binder_node的工作項(xiàng)，即將成員work的值置為BINDER_WORK_NODE，并將
    // 它添加到相應(yīng)進(jìn)程的todo隊(duì)列中等待處理
    struct binder_work work;

    union {
        struct rb_node rb_node;
        struct hlist_node dead_node;
    };

    // 指向宿主進(jìn)程，宿主進(jìn)程使用一個(gè)紅黑樹來維護(hù)它內(nèi)部所有Binder實(shí)體對(duì)象，而每一個(gè)
    // Binder實(shí)體對(duì)象的成員變量rb_node就正好是這個(gè)紅黑樹的一個(gè)節(jié)點(diǎn)。如果Binder實(shí)體對(duì)象
    // 的宿主進(jìn)程已經(jīng)死亡，那么該Binder實(shí)體對(duì)象就會(huì)通過它的成員變量dead_node保存在一個(gè)全
    // 局的hash列表中。
    struct binder_proc *proc;

    // 一個(gè)Binder實(shí)體對(duì)象可能會(huì)同時(shí)被多個(gè)Client組件引用，因此Binder驅(qū)動(dòng)使用結(jié)構(gòu)體
    // binder_ref來描述這些引用關(guān)系，并且將引用了同一個(gè)Binder實(shí)體對(duì)象的所有引用都保存在
    // 一個(gè)hash列表中。這個(gè)hash列表通過Binder實(shí)體對(duì)象的refs成員來描述，而Binder驅(qū)動(dòng)通
    // 過refs就可以知道有哪些Client組件引用了同一個(gè)Binder實(shí)體對(duì)象
    struct hlist_head refs;

    int internal_strong_refs;       // 描述Bidner實(shí)體對(duì)象的強(qiáng)引用計(jì)數(shù)
    int local_weak_refs;            // 描述Binder實(shí)體對(duì)象的弱引用計(jì)數(shù)
    int local_strong_refs;          // 描述Bidner實(shí)體對(duì)象的強(qiáng)引用計(jì)數(shù)

    void __user *ptr;       // 描述用戶空間中的Service組件，指向Service的影子對(duì)象
    void __user *cookie;    // 描述用戶空間中的Service組件的地址，指向Service的地址

     // 當(dāng)Binder實(shí)體對(duì)象請求Service執(zhí)行某個(gè)操作時(shí)，會(huì)增加該Service的強(qiáng)/弱引用計(jì)數(shù)，
     // has_strong_ref和has_weak_ref被置1；
     // 當(dāng)Service完成Binder所請求的操作后，會(huì)遞減該Service的強(qiáng)/弱引用計(jì)數(shù)，has_strong_ref和has_weak_ref被置0；
     // Binder實(shí)體在請求Service增/減強(qiáng)/弱引用計(jì)數(shù)的過程中，會(huì)將
     // pending_strong_ref或pending_weak_ref置1；
     // 當(dāng)Service完成增/減強(qiáng)/弱引用計(jì)數(shù)之后，會(huì)將這兩個(gè)成員變量置為0。
    unsigned has_strong_ref:1;     
    unsigned pending_strong_ref:1;
    unsigned has_weak_ref:1;
    unsigned pending_weak_ref:1;

    // 描述Binder對(duì)象是否正在處理一個(gè)異步事務(wù)。Binder驅(qū)動(dòng)程序?qū)⒁粋€(gè)事務(wù)保存在todo隊(duì)列中
    // 表示將由該線程來處理該事務(wù)。每個(gè)事務(wù)都關(guān)聯(lián)著一個(gè)Binder實(shí)體對(duì)象，要求與該Binder實(shí)
    // 體對(duì)象對(duì)應(yīng)的Service組件在指定線程中處理該事務(wù)。然而，當(dāng)Binder驅(qū)動(dòng)發(fā)現(xiàn)一個(gè)事務(wù)是異
    // 步事務(wù)時(shí)，就會(huì)將它保存在目標(biāo)Binder實(shí)體對(duì)象的一個(gè)異步事務(wù)隊(duì)列中，這個(gè)異步事務(wù)隊(duì)列就
    // 是由成員變量async_todo來描述的。異步事務(wù)的定義是那些單向的進(jìn)程間通信請求，即不需
    // 要等待應(yīng)答的進(jìn)程間通信請求，與此相對(duì)的是同步事務(wù)。因?yàn)椴恍枰却龖?yīng)答，Binder驅(qū)動(dòng)就
    // 認(rèn)為異步事務(wù)優(yōu)先級(jí)低于同步事務(wù)，具體表現(xiàn)為在同一時(shí)刻，一個(gè)Binder實(shí)體對(duì)象的所有異步
    // 事務(wù)最多只有一個(gè)會(huì)得到處理，其余的都等待在異步事務(wù)隊(duì)列中，而同步事務(wù)無此限制。
    unsigned has_async_transaction:1;

    // 描述Binder實(shí)體對(duì)象是否可以接收包含有文件描述符的進(jìn)程間通信數(shù)據(jù)。1表示可以接收，0表
    // 示禁止接收。當(dāng)一個(gè)進(jìn)程向另一個(gè)進(jìn)程發(fā)送的數(shù)據(jù)中包含有文件描述符時(shí)，Binder驅(qū)動(dòng)程序就
    // 會(huì)自動(dòng)在目標(biāo)進(jìn)程中打開一個(gè)相同的文件。基于安全性考慮，Binder程序就要通過該變量防止
    // 源進(jìn)程在目標(biāo)進(jìn)程中打開文件。
    unsigned accept_fds:1;

    // 表示Binder實(shí)體對(duì)象在處理來自Client進(jìn)程的請求時(shí)，他所要求的處理線程（即Server進(jìn)程
    // 中的一個(gè)線程）應(yīng)具備的最小線程優(yōu)先級(jí)。
    unsigned min_priority:8;       
    struct list_head async_todo;
};
 

以上是“struct binder_node的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！