在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

OpenHarmony HDF HDI的IPC模式具體實現方法和驅動框架能力

電子發燒友開源社區 ? 來源:OpenAtom OpenHarmony ? 作者:OAOH ? 2021-09-22 14:55 ? 次閱讀

HDI接口概述

回顧之前的文章,HDF 驅動框架的一個重要功能是為系統提供穩定的統一的硬件接口,這樣才能保證系統服務可以運行在不同硬件上而不需要額外的適配工作,HDI(Hardware Device Interfaces)正是為了實現該目的而設計。

HDI 是對硬件功能的較高層次抽象接口,各類外設完成 HDI 接口定義后便只會在 HDI 的兼容性規則下進行變更,從而保證接口的穩定性。具體的驅動實現不需要再重復定義 HDI 接口,只需要按需實現即可接入系統功能。

在不同量級的 OpenHarmony 系統上,HDI 存在兩種部署形態,IPC 模式和直通模式。

在輕量級 OpenHarmony 系統上,出于減小系統性能負載考慮,HDI 實現為用戶態共享庫,由系統服務直接加載 HDI 實現到自己進程中函數調用使用。HDI 實現封裝具體的用戶態-內核態交互過程,當需要訪問驅動程序時使用 IO Service 請求將消息通過 system call 方式調用到內核驅動實現。

在標準 OpenHarmony 系統上,HDI 以獨立服務進程方式部署,系統服務只加載 HDI 客戶端實現到自己進程中,實際業務運行在獨立進程中,客戶端通過 IPC 與服務端交互,便于架構解耦、權限管理。

HDI接口實現

直通模式為函數實現方式,無論調用還是實現都不需要其他組件支持即可實現,這里將重點分析 IPC 模式的實現。

HDI發布

HDI IPC 模式基于 OpenHarmony 系統通信框架的通用模型,但是因為驅動很多時候涉及到底層操作和多系統遷移的場景而使用C語言編寫,所以驅動框架還提供了 HDI 服務的 C 語言實現的基礎組件,C++實現則主要使用系統通信框架組件。

HDI 服務發布基于 UHDF(用戶態 HDF 驅動框架)實現,通用的服務發布實現如下。

1. 實現驅動入口

int SampleDriverBind(struct HdfDeviceObject *deviceObject){    HDF_LOGE("SampleDriverBind enter!");    static struct IDeviceIoService testService = {        .Dispatch = SampleServiceDispatch, // 服務回調接口    };    deviceObject->service = &testService;    return HDF_SUCCESS;} int SampleDriverInit(struct HdfDeviceObject *deviceObject){    HDF_LOGE("SampleDriverInit enter");     return HDF_SUCCESS;} void SampleDriverRelease(struct HdfDeviceObject *deviceObject){    HDF_LOGE("SampleDriverRelease enter");    return;} struct HdfDriverEntry g_sampleDriverEntry = {    .moduleVersion = 1,    .moduleName = "sample_driver",    .Bind = SampleDriverBind,    .Init = SampleDriverInit,    .Release = SampleDriverRelease,};
HDF_INIT(g_sampleDriverEntry);

首先要添加一個 UHDF 驅動用于發布 IoService 服務,IoService 設備服務即為 HDI 服務實體。實現方式與 KHDF 驅動一致。

2. 實現服務響應接口

int32_t SampleServiceOnRemoteRequest(struct HdfDeviceIoClient *client, int cmdId,    struct HdfSBuf *data, struct HdfSBuf *reply){    switch (cmdId) {        case SAMPLE_SERVICE_PING:            return SampleServiceStubPing(client, data, reply);        … …        default:            HDF_LOGE("SampleServiceDispatch: not support cmd %d", cmdId);            return HDF_ERR_INVALID_PARAM;    }}static int32_t SampleServiceDispatch(struct HdfDeviceIoClient *client, int cmdId,    struct HdfSBuf *data, struct HdfSBuf *reply){    return SampleServiceOnRemoteRequest(client, cmdId, data, reply);}

當收到 HDI 調用時,服務響應接口"SampleServiceDispatch"將會被調用。

  • client 調用者對象,在用戶態驅動中暫時未支持
  • cmdId 調用命令字,用于區分調用的 API
  • data 調用入參序列化對象,在 IPC 調用場景為 parcel 對象的 C 語言封裝,入參需要使用序列化接口從 data 對象中獲取后再使用
  • reply 調用出參對象,需要返回給調用的信息寫入該序列化對象

如果 C++實現客戶端可以使用下面接口將 sbuf 對象轉換為 parcel 對象后操作:

int32_t SbufToParcel(struct HdfSBuf *sbuf, OHOS::MessageParcel **parcel);
3. UHDF 驅動配置
platform :: host {    hostName = "sample_host";    priority = 50;    sample_device :: device {        device0 :: deviceNode {            policy = 2;            priority = 100;            moduleName = "libsample_driver.z.so";            serviceName = "sample_driver_service";        }    }}

參數說明:

  • host 一個 host 節點即為一個獨立進程,如果需要獨立進程,新增屬于自己的 host 節點
  • policy 服務發布策略,HDI 服務設置為 2
  • moduleName 驅動實現庫名
  • serviceName 服務名稱,請保持全局唯一性

因為 HDI 服務 C 和 C++實現使用的 IPC 組件不一樣,面向對象實現也不一致,所以在具體實現上存在一些差異。

HDI基礎組件UHDF 框架為了支持 HDI 實現,提供了以下基礎組件(僅用于 C 語言 HDI 實現):
  • SBuf

SBuf 是同時支持 KHDF 和 UHDF 驅動 IoService 消息序列化的工具對象。在 UHDF IPC 通信場景中,SBuf 可以與系統 IPC 框架序列化對象 MessageParcel 對象(僅支持 C++)相互轉換,從而實現 C 和 C++實現的 IPC 互通。

常用 API 如下:

struct HdfSBuf;struct HdfSbufImpl;struct HdfRemoteService;
/** * @brief HdfSBuf類型定義。 * * @since 1.0 */enum HdfSbufType {    SBUF_RAW = 0,   /* 用于用戶態內核態通信的sbuf類型 */    SBUF_IPC,       /* 用于跨進程通信的sbuf類型 */    SBUF_IPC_HW,    /* 用于擴展的預留類型 */    SBUF_TYPE_MAX,  /* sbuf類型最大值 */};

bede5c9e-0b50-11ec-8fb8-12bb97331649.png

上述接口均有對應的寫入接口,不再一一列舉,可查閱官網API參考文檔。

  • RemoteService

RemoteService 對象和系統 IPC 框架中的 IRemoteObject 對象(僅支持 C++)對應并可以相互轉換,表示一個 IPC 對象。相關 API 說明:
// 消息分發器,用于服務端響應調用或者在客戶端發起調用struct HdfRemoteDispatcher {    int (*Dispatch)(struct HdfRemoteService *, int, struct HdfSBuf *, struct HdfSBuf *);};
// RemoteService 死亡回調對象struct HdfDeathRecipient {    void (*OnRemoteDied)(struct HdfDeathRecipient *, struct HdfRemoteService *);};
struct HdfRemoteService {    struct HdfObject object_;    struct HdfObject *target;    struct HdfRemoteDispatcher *dispatcher;    bool isHw;};// 以自定義的消息分發器實例化一個RemoteServicestruct HdfRemoteService *HdfRemoteServiceObtain(    struct HdfObject *object, struct HdfRemoteDispatcher *dispatcher);
// 回收RemoteService對象void HdfRemoteServiceRecycle(struct HdfRemoteService *service);
// 添加RemoteService的死亡通知,如果對應RemoteService的進程異常退出,HdfDeathRecipient的回調接口將被調用voidHdfRemoteServiceAddDeathRecipient(structHdfRemoteService*service,structHdfDeathRecipient*recipient);
基于 RemoteService 實現一個服務端的示例:
int SampleServiceStubDispatch(    struct HdfRemoteService* service, int code, struct HdfSBuf *data, struct HdfSBuf *reply){    // IPC 調用響應接口    int ret = HDF_FAILURE;    switch (code) {        case SAMPLE_IF_0: {            // do something            break;        }        default: {            ret = HDF_ERR_INVALID_PARAM;        }    }    return ret;}bool SampleStubConstruct(){    // 構造消息分發器,實現消息處理回調    static struct HdfRemoteDispatcher dispatcher = {        .Dispatch = SampleServiceStubDispatch};// 實例化RemoteService    inst->remote = HdfRemoteServiceObtain((struct HdfObject *)inst, &dispatcher);    if (inst->remote == NULL) {        HDF_LOGE("Device service manager failed to obtain remote service");        return false;}……

直接基于 RemoteService 實現服務端只適用于需要實現匿名 IPC 服務的情況,基于 UHDF 發布 HDI 服務只需要實現 Driver 綁定的 IoService 即可。

RemoteService 客戶端對象只能從 SBuf HdfSBufReadRemoteService 接口獲取。

HDI實現

  • Driver 為 HDI 服務的驅動入口實現
  • IoService 為 HDI 服務的服務入口實現,IoService 的 Dispatch 方法中調用 ServiceStub 中的真正服務響應接口(OnRemoteRequest)
  • ServiceStub 為服務端實現對象,主要處理與 IPC 相關的業務邏輯,在這里完成參數反序列化后調用真正的 Service 實現接口,即 ServiceImpl 接口
  • ServiceImpl 為 HDI 接口的真正實現,這里不關注 IPC 過程,只實現函數接口。
  • 驅動框架提供了實現的樣例代碼,可參考 gitee driver 代碼倉。

HDI接口調用

HDI驅動框架HDI接口

HDI 服務管理功能由驅動框架 DeviceManager 實現,所以驅動框架提供了 HDI 服務管理相關 HDI 接口。

C++實現:

namespace OHOS {namespace HDI {namespace ServiceManager {namespace V1_0 {
struct IServiceManager : public IRemoteBroker {public:    DECLARE_INTERFACE_DESCRIPTOR(u"HDI.IServiceManager.V1_0");    // get()靜態方法用于獲取IServiceManager對象實例    static ::sptr Get();    // GetService()接口是真正提供的HDI接口,用于查詢并獲取其他HDI服務的客戶端對象    virtual ::sptr GetService(const char* serviceName) = 0;};} // namespace V1_0} // namespace ServiceManager} // namespace HDI}//namespaceOHOS

C 實現:

#ifdef __cplusplusextern "C" {#endif /* __cplusplus */
struct HDIServiceManager {    struct HdfRemoteService *remote;
    struct HdfRemoteService *(*GetService)(struct HDIServiceManager *self, const char* serviceName);};
struct HDIServiceManager *HDIServiceManagerGet(void);void HDIServiceManagerRelease(struct HDIServiceManager *servmgr);
#ifdef __cplusplus}#endif/*__cplusplus*/

C 語言因為缺少原生的面向對象支持,這里我們采用 OOC 的實現,函數方法 HDIServiceManagerGet/Release 用于 HDIServiceManager 對象的實例化和釋放,HDI 接口關聯在接口對象內部成員中,與 C++實現類似。

HDI客戶端實現

HDI 客戶端同時支持 C 和 C++實現,實現方法較為簡單,只需 realize HDI 接口類即可。提供 C++實現基于系統 IPC 子系統的統一模型,C 語言基于 RemoteService 和 SBuf 組件實現,但是有一些公共的約定:

1. 客戶端提供接口對象,接口與對象綁定且必須與 HDI 一致

2. 提供服務接口對象的實例化和釋放接口。

3. 客戶端實現 IPC 過程,只為調用者暴露函數化接口。

HDI接口調用

HDI 客戶端接口已經提供了服務獲取接口,調用者調用服務獲取接口后再調用服務對象方法即可完成 HDI 調用。

這里以服務管理 HDI 接口為例:

C++接口調用:

#include 
void GetTestService(){        auto servmgr = IServiceManager::Get();    if (servmgr == nullptr) {    HDF_LOGE("failed to get IServiceManager");    return;  }
    auto sampleService = servmgr->GetService(TEST_SERVICE_NAME);  if (sampleService == nullptr) {    HDF_LOGE("failed to get TEST_SERVICE");    return;  }    // do something}

C 接口調用:

#include 
void GetTestService(){        struct HDIServiceManager *servmgr = HDIServiceManagerGet();    if (servmgr == nullptr) {    HDF_LOGE("failed to get IServiceManager");    return;  }
    struct HdfRemoteService *sampleService = servmgr->GetService(servmgr, TEST_SERVICE_NAME);  if (sampleService == nullptr) {    HDF_LOGE("failed to get TEST_SERVICE");    return;  }    // do something}

總結

本文介紹了 HDI 的總體方案,重點介紹了 HDI 的 IPC 模式具體實現方法和驅動框架能力,相信對讀者理解和使用 HDI 有所幫助。

編輯:jq
聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • HDI
    HDI
    +關注

    關注

    6

    文章

    202

    瀏覽量

    21365
  • C++
    C++
    +關注

    關注

    22

    文章

    2114

    瀏覽量

    73899
  • 代碼
    +關注

    關注

    30

    文章

    4841

    瀏覽量

    69143
  • OpenHarmony
    +關注

    關注

    25

    文章

    3753

    瀏覽量

    16673

原文標題:OpenHarmony HDF HDI基礎能力分析與使用

文章出處:【微信號:HarmonyOS_Community,微信公眾號:電子發燒友開源社區】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    迅為RK3568開發板篇OpenHarmony實操HDF驅動控制LED-編寫應用APP

    HDF_FRAMEWORKS 和 HDF_ADAPTER,它們分別指向 HDF(HardwareDriver Foundation,硬件驅動框架
    發表于 02-06 10:27

    迅為RK3568開發板篇OpenHarmony實操HDF驅動控制LED-添加內核編譯

    編譯內核時將該 HDF 驅動編譯到鏡像中,接下來編寫驅動編譯腳本 Makefile,代碼如下所示: 加入編譯體系,填加模塊目錄到 drivers/hdf_core/adapter/kh
    發表于 01-22 10:35

    迅為RK3568開發板篇OpenHarmony實操HDF驅動控制LED-編寫內核 LED HDF 驅動程序

    接下來編譯 LED 驅動,該驅動用于在基于華為設備框架HDF)的系統中控制 LED 燈的開關,完整代碼如下所示: 更多內容可以關注:迅為RK3568開發板篇
    發表于 01-17 15:13

    迅為RK3568開發板篇OpenHarmony配置HDF驅動控制LED-新增 topeet子系統-編寫 bundle.json文件

    OpenHarmony OS)生態系統下的一個名為\"demos\"的組件。 description: \"topeet demos\" -它描述了組件的簡短說明
    發表于 01-15 15:59

    迅為RK3568開發板篇OpenHarmony配置HDF驅動控制LED-新增 topeet子系統

    程序目錄 ├── led_driver.c:內核 LED HDF 驅動程序 └── Makefile:內核 LED HDF 驅動編譯腳本 更多內容可以關注:迅為RK3568開發板篇
    發表于 01-13 15:59

    迅為RK3568開發板篇OpenHarmony配置HDF驅動控制LED-配置創建私有配置文件

    和 Init 方法傳遞給驅動。 topeet_config.hcs 具體內容如下所示: 驅動私有配置文件寫完之后,我們需要將該配置文件添加到板級配置入口文件vendor/hihope
    發表于 01-10 11:13

    OpenHarmony程序分析框架論文入選ICSE 2025

      近日,ICSE 2025軟件工程實踐Track放榜,面向OpenAtom OpenHarmony(以下簡稱“OpenHarmony”)的ArkTS程序分析基礎框架--方舟程序分析器(論文題目為
    的頭像 發表于 01-02 13:41 ?253次閱讀
    <b class='flag-5'>OpenHarmony</b>程序分析<b class='flag-5'>框架</b>論文入選ICSE 2025

    HDI盲埋孔工藝及制程能力你了解多少?

    HDI技術通過 增加盲埋孔來實現高密度布局 ,適用于高端服務器、智能手機、多功能POS機和安防攝像機等領域。通訊和計算機行業對HDI線路板需求較高,推動了科技的進步。目前,HDI板在國
    的頭像 發表于 12-18 17:15 ?1437次閱讀
    <b class='flag-5'>HDI</b>盲埋孔工藝及制程<b class='flag-5'>能力</b>你了解多少?

    HDI盲埋孔工藝及制程能力你了解多少?

    HDI激光填孔工藝能力 1、半固化片壓合填孔 適用條件: 板厚 ≤ 0.3mm、孔徑 ≤ 0.2mm; 方法: 在上述條件下,可采用半固化片進行填膠塞孔。 2、電鍍填孔 介質層與孔徑比例: 需滿足
    發表于 12-18 17:13

    鴻蒙開發:【OpenHarmony 4.0 Release指導】

    OpenHarmony 4.0版本如期而至,開發套件同步升級到API 10。相比3.2 Release版本,新增4000多個API,應用開發能力更加豐富;HDF新增200多個HDI接口
    的頭像 發表于 05-14 09:59 ?1668次閱讀
    鴻蒙開發:【<b class='flag-5'>OpenHarmony</b> 4.0 Release指導】

    開發者手機 AI - 目標識別 demo

    Network Runtime 神經網絡運行時,作為中間橋梁連通上層AI推理框架和底層加速芯片,實現AI模型的跨芯片推理計算。提供統一AI芯片驅動接口,使AI芯片驅動能夠接入
    發表于 04-11 16:14

    OpenHarmony南向能力征集令

    1、適配過程中缺少哪些接口能力或者南向能力,需要OpenHarmony去補齊的?例如內核、編譯、器件適配、單板適配等; 2、對標linux,需要OpenHarmony提供哪些
    發表于 04-09 15:32

    鴻蒙開發實戰:【Hdf Framework】

    該倉主要存放OpenHarmony驅動子系統核心源碼信息(包括驅動框架、配置管理、配置解析、驅動通用框架
    的頭像 發表于 03-21 20:29 ?605次閱讀
    鴻蒙開發實戰:【<b class='flag-5'>Hdf</b> Framework】

    OpenHarmony4.0源碼解析之媒體框架

    及 audio-source 插件調用音頻框架的播放及采集功能來實現音頻的播放與錄制;通過 surface-sink 調用圖形框架,video-decoder 調用解碼驅動
    的頭像 發表于 02-26 22:05 ?1125次閱讀
    <b class='flag-5'>OpenHarmony</b>4.0源碼解析之媒體<b class='flag-5'>框架</b>

    鴻蒙OS跨進程IPC與RPC通信

    ) = 0; // 定義業務函數 }; 3.定義和實現服務端TestAbilityStub 該類是和IPC框架相關的實現,需要繼承 IRemoteStub。Stub端作為接收請求的一
    發表于 02-17 14:20
    主站蜘蛛池模板: 久久综合狠狠综合久久 | 国产精品免费久久久久影院 | 欧美性xxxx极品高清 | 四虎最新网址入口 | 亚洲伦理一区二区三区 | 久久精品国产福利 | 在线观看黄色x视频 | 午夜美女视频在线观看高清 | 中文字幕在线视频第一页 | 日一日操一操 | 亚洲天堂成人网 | 国产特黄一级毛片特黄 | 午夜天堂影院 | 手机在线观看a | 亚洲伊人99综合网 | 手机看片日本 | 亚洲一区二区视频 | 国产免费播放 | 2021国产成人精品久久 | 未成人禁止视频高清在线观看 | 久久riav国产精品 | 日韩卡1卡2卡三卡四卡二卡免 | 中文字幕一区精品欧美 | 日本午夜大片 | 成人午夜久久 | 天天怕夜夜怕狠狠怕 | 日不卡| 鲁老汉精品视频在线观看 | 朋友夫妇和交换性bd高清 | 五月婷婷俺也去开心 | 亚洲男人的天堂成人 | 午夜69成人做爰视频网站 | 日本丶国产丶欧美色综合 | 成人久久精品 | 4438x成人网最大色成网站 | 久久天天躁狠狠躁夜夜爽蜜月 | 天堂网在线资源www最新版 | 未满十八18周岁禁止免费国产 | 日本黄色美女网站 | 午夜情趣视频 | 人人澡人人搞 |