《鴻蒙智能互聯(lián)設備開發(fā)（微課版）》 課件匯 苗玉虎 第5-8章 LiteOS-A 內(nèi)核 -智能出行設備開發(fā)

5.1.1LiteOS-A內(nèi)核簡介通過本節(jié)學習，您可以：了解LiteOS-A內(nèi)核簡介LiteOS-A內(nèi)核簡介LiteOS-A適配的系統(tǒng)及設備類型：小型系統(tǒng)（smallsystem）面向應用處理器例如ArmCortex-A的設備，支持的設備最小內(nèi)存為1MB，可以提供更高的安全能力、標準的圖形框架、視頻編解碼的多媒體能力?？芍蔚漠a(chǎn)品如智能家居領(lǐng)域的IPCamera、電子貓眼、路由器以及智慧出行域的行車記錄儀等。LiteOS-A要求設備具備一定的處理能力，對比LiteOS-M，LiteOS-A支持以下特性：（1）MMU支持：通過MMU支持內(nèi)核態(tài)和用戶態(tài)分離，支持虛擬單元；（2）支持獨立進程：調(diào)度對象分別為進程、線程；（3）支持文件系統(tǒng)：包括虛擬文件和塊設備等；（4）支持更復雜的IPC：包括LiteIPC等；（5）支持多核調(diào)度：支持雙核MCU，支持雙核調(diào)度；（6）支持POSIX3接口：為APP開發(fā)提供更多幫助。LiteOS-A內(nèi)核簡介LiteOS-A的源碼目錄：關(guān)鍵目錄：arch:存放了arm架構(gòu)相關(guān)的代碼，以及中斷管理相關(guān)代碼compat:POSIX標準目的是為了提供源碼級的軟件可移植性。一個系統(tǒng)提供了POSIX接口，則任何其它的系統(tǒng)可以通過POSIX調(diào)用該系統(tǒng)drivers:內(nèi)核驅(qū)動代碼，分別對應塊設備驅(qū)動、字符設備驅(qū)動、內(nèi)存設備驅(qū)動LiteOS-A內(nèi)核簡介關(guān)鍵目錄：kernel:base:基礎(chǔ)內(nèi)核，進程管理、內(nèi)存管理、內(nèi)核通信機制、時間管理、軟件定時器等模塊。include:內(nèi)核相關(guān)模塊頭文件。LiteOS-A的源碼目錄：謝謝5.1.2LiteOS-A內(nèi)核架構(gòu)通過本節(jié)學習，您可以：了解LiteOS-A內(nèi)核架構(gòu)LiteOS-A內(nèi)核架構(gòu)LiteOS-A內(nèi)核分為內(nèi)核空間和用戶空間，如圖所示。LiteOS-A內(nèi)核架構(gòu)（1）基礎(chǔ)內(nèi)核：進程管理：支持進程和線程，采用了高優(yōu)先級優(yōu)先加同優(yōu)先級時間片輪轉(zhuǎn)的搶占式調(diào)度機制。內(nèi)存管理：對物理內(nèi)存和虛擬內(nèi)存分別進行管理。中斷異常：對中斷的異常處理。時間管理：對操作系統(tǒng)時間進行管理，提供給應用程序所有和時間有關(guān)的服務。通信機制：包括事件、信號量、互斥鎖、消息隊列、信號等。1.

內(nèi)核空間LiteOS-A內(nèi)核架構(gòu)（2）擴展組件：主要包括文件系統(tǒng)、網(wǎng)絡協(xié)議、權(quán)限管理、動態(tài)加載、調(diào)測工具等。文件系統(tǒng)：輕量級內(nèi)核支持FAT，JFFS2，NFS，ramfs，procfs等眾多文件系統(tǒng)，并對外提供完整的POSIX標準的操作接口；內(nèi)部使用VFS（VirtualFileSystems，虛擬文件系統(tǒng)）層作為統(tǒng)一的適配層框架，方便移植新的文件系統(tǒng)，各個文件系統(tǒng)也能自動利用VFS層提供的豐富的功能。LiteOS-A內(nèi)核架構(gòu)網(wǎng)絡協(xié)議：網(wǎng)絡協(xié)議基于開源LWIP（LightWeightIP協(xié)議）構(gòu)建。支持多種協(xié)議：IP、ICMP、ND、MLD、UDP、TCP、IGMP、ARP、PPP支持的API：socketAPI網(wǎng)絡協(xié)議的擴展特性：多網(wǎng)絡接口IP轉(zhuǎn)發(fā)、TCP擁塞控制、RTT估計和快速恢復、快速重傳。支持多種應用程序LiteOS-A內(nèi)核架構(gòu)支持的協(xié)議：IP協(xié)議：包括IPV4和IPV6，支持IP分片于重裝，支持多網(wǎng)絡接口下數(shù)據(jù)包轉(zhuǎn)發(fā)。ICMP協(xié)議：用于網(wǎng)絡調(diào)試維護。ND（NeighborDiscovery）協(xié)議：IP6鄰居發(fā)現(xiàn)協(xié)議。MLD協(xié)議：組播偵聽發(fā)現(xiàn)協(xié)議，于IPv6組播中組成員管理。UDP協(xié)議：用戶數(shù)據(jù)包協(xié)議。TCP：支持TCP擁塞控制，RTT估計，快恢復和重傳等。IGMP：用于網(wǎng)絡組管理，可以實現(xiàn)多播數(shù)據(jù)的接收。ARP協(xié)議：地址解析協(xié)議。PPP協(xié)議：包括PPPoS（串口點對點協(xié)議）、PPPoE（以太網(wǎng)上的點對點協(xié)議）。LiteOS-A內(nèi)核架構(gòu)適用的應用程序：HTTP(S)服務SNTP客戶端SMTP(S)客戶端ping工具NetBIOS名稱服務mDNS響應程序MQTT客戶端TFTP服務DHCP客戶端DNS客戶端AutoIP/APIPA（零配置）SNMP代理LiteOS-A內(nèi)核架構(gòu)（3）HDF框架HDF框架是外設驅(qū)動統(tǒng)一標準框架，提供了GPIO、SDIO、I2C、USB、WLAN等各種外設接口方式。HDF框架特性：支持多內(nèi)核平臺。支持用戶態(tài)驅(qū)動?？膳渲媒M件化驅(qū)動模型?；谙⒌尿?qū)動接口模型?；趯ο蟮尿?qū)動、設備管理。HDI（HardwareDriverInterface）統(tǒng)一硬件接口。支持電源管理、PnP（Plug-and-Play，即插即用）。LiteOS-A內(nèi)核架構(gòu)LiteOS-A內(nèi)核架構(gòu)的頂部是用戶空間，用戶空間主要是用戶進程和POSIX接口組成。OpenHarmony內(nèi)核使用musllibc庫，支持標準POSIX接口，開發(fā)者可基于POSIX標準接口開發(fā)內(nèi)核之上的組件及應用。2.用戶空間謝謝5.1.3LiteOS-A內(nèi)核態(tài)啟動流程通過本節(jié)學習，您可以：了解LiteOS-A內(nèi)核態(tài)啟動流程LiteOS-A內(nèi)核態(tài)啟動流程內(nèi)核啟動流程如圖所示。LiteOS-A內(nèi)核態(tài)啟動流程內(nèi)核啟動流程包含匯編啟動階段和C語言啟動階段兩部分。匯編啟動階段完成CPU初始設置，關(guān)閉dcache/icache與MMU，使能FPU及neon，設置MMU建立虛實地址映射，設置系統(tǒng)棧，清理bss段，調(diào)用C語言main函數(shù)等。C語言啟動階段包含OsMain函數(shù)及開始調(diào)度等。LiteOS-A內(nèi)核態(tài)啟動流程OsMain函數(shù)用于內(nèi)核基礎(chǔ)初始化和架構(gòu)、板級初始化等，其整體由內(nèi)核啟動框架主導初始化流程，如圖所示。LiteOS-A內(nèi)核態(tài)啟動流程①LOS_INIT_LEVEL_EARLIEST：最早期初始化。不依賴架構(gòu)，單板以及后續(xù)模塊會對其有依賴的純軟件模塊初始，例如：內(nèi)核Trace模塊初始化。②LOS_INIT_LEVEL_ARCH_EARLY：架構(gòu)早期初始化。與架構(gòu)相關(guān)，后續(xù)模塊會對其有依賴的模塊初始化，如啟動過程中非必需的功能，建議放到⑥LOS_INIT_LEVEL_ARCH層。LiteOS-A內(nèi)核態(tài)啟動流程③LOS_INIT_LEVEL_PLATFORM_EARLY：平臺早期初始化。與單板平臺、驅(qū)動相關(guān)，后續(xù)模塊會對其有依賴的模塊初始化，如啟動過程中必需的功能，建議放到⑦LOS_INIT_LEVEL_PLATFORM層。④LOS_INIT_LEVEL_KMOD_PREVM：內(nèi)存初始化前的內(nèi)核模塊初始化。在內(nèi)存初始化之前需要使能的模塊初始化。LiteOS-A內(nèi)核態(tài)啟動流程⑤LOS_INIT_LEVEL_VM_COMPLETE：基礎(chǔ)內(nèi)存就緒后的初始化。此時內(nèi)存初始化完畢，需要進行使能且不依賴進程間通訊機制與系統(tǒng)進程的模塊初始化。⑥LOS_INIT_LEVEL_ARCH：架構(gòu)后期初始化。與架構(gòu)拓展功能相關(guān)，后續(xù)模塊會對其有依賴的模塊初始化。LiteOS-A內(nèi)核態(tài)啟動流程⑦LOS_INIT_LEVEL_PLATFORM：平臺后期初始化。單板平臺、驅(qū)動相關(guān)，后續(xù)模塊會對其有依賴的模塊初始化，例如：驅(qū)動內(nèi)核抽象層初始化（mmc、mtd）。⑧LOS_INIT_LEVEL_KMOD_BASIC：內(nèi)核基礎(chǔ)模塊初始化。內(nèi)核可拆卸的基礎(chǔ)模塊初始化。例如：VFS初始化。LiteOS-A內(nèi)核態(tài)啟動流程⑨LOS_INIT_LEVEL_KMOD_EXTENDED：內(nèi)核擴展模塊初始化。內(nèi)核可拆卸的擴展模塊初始化。例如：系統(tǒng)調(diào)用初始化、ProcFS初始化、Futex初始化、HiLog初始化、LiteIPC初始化。⑩LOS_INIT_LEVEL_KMOD_TASK：內(nèi)核任務創(chuàng)建。進行內(nèi)核任務的創(chuàng)建（內(nèi)核任務，軟件定時器任務）。例如：資源回收系統(tǒng)常駐任務的創(chuàng)建、SystemInit任務創(chuàng)建、CPU占用率統(tǒng)計任務創(chuàng)建等。謝謝5.1.4LiteOS-A用戶態(tài)啟動流程通過本節(jié)學習，您可以：了解LiteOS-A用戶態(tài)啟動流程LiteOS-A用戶態(tài)啟動流程用戶態(tài)啟動是從根進程開始的。根進程是系統(tǒng)的第一個用戶態(tài)進程，進程ID為1。用戶態(tài)啟動進程樹如圖所示。1號進程接下來會創(chuàng)建和啟動其他的用戶態(tài)進程例如/bin/shell。LiteOS-A用戶態(tài)啟動流程鴻蒙中的init進程作用類似于Linux中的init進程，主要作用是完成系統(tǒng)啟動后，用戶可以操作前的一些初始化操作，例如孵化一些用戶的服務，創(chuàng)建一些必要的文件目錄結(jié)構(gòu)等。Init進程是由SysemInit()函數(shù)來啟動的，SystemInit()函數(shù)代碼如下所示：

SystemInit()

ProcFsInit();

mem_dev_register();

imx6ull_driver_init();

imx6ull_mount_rootfs();

DeviceManagerStart();//HDF，加載驅(qū)動，使外設可以正常工作。

uart_dev_init();

......

OsUserInitProcess();LiteOS-A用戶態(tài)啟動流程在SystemInit()函數(shù)中，通過OsUserInitProcess()啟動init進程，具體是通過OsUserInitProcessStart()函數(shù)來實現(xiàn)的。OsUserInitProcessStart()函數(shù)的代碼如下：

STATICUINT32OsUserInitProcessStart(UINT32processID,TSK_INIT_PARAM_S*param)

{

UINT32intSave;

INT32taskID;

INT32ret;

taskID=OsCreateUserTask(processID,param);

if(taskID<0){

returnLOS_NOK;

}

ret=LOS_SetTaskScheduler(taskID,LOS_SCHED_RR,OS_TASK_PRIORITY_LOWEST);

if(ret<0){

PRINT_ERR("Userinitprocesssetschedulerfailed!ERROR:%d\n",ret);

SCHEDULER_LOCK(intSave);

(VOID)OsTaskDeleteUnsafe(OS_TCB_FROM_TID(taskID),OS_PRO_EXIT_OK,intSave);

return-ret;

}

returnLOS_OK;

}謝謝5.2.1中斷與異常處理的概念和機制通過本節(jié)學習，您可以：了解中斷與異常處理的概念和機制中斷與異常處理的概念中斷異常處理是操作系統(tǒng)對運行期間發(fā)生的異常情況（芯片硬件異常）進行處理的一系列動作，例如虛擬內(nèi)存缺頁異常、打印異常發(fā)生時函數(shù)的調(diào)用棧信息、CPU現(xiàn)場信息、任務的堆棧情況等。異常指可以打斷CPU正常運行流程的一些事情，如未定義指令異常、試圖修改只讀的數(shù)據(jù)異常、不對齊的地址訪問異常等。中斷與異常處理機制LiteOS-A的中斷異常處理流程：外設可以在沒有CPU介入的情況下完成一定的工作，但某些情況下也需要CPU為其執(zhí)行一定的工作。當外設需要CPU時，將產(chǎn)生一個中斷信號，該信號連接至中斷控制器。中斷控制器是一方面接收其它外設中斷引腳的輸入，另一方面它會發(fā)出中斷信號給CPU?？梢酝ㄟ^對中斷控制器編程來打開和關(guān)閉中斷源、設置中斷源的優(yōu)先級和觸發(fā)方式。CPU收到中斷控制器發(fā)送的中斷信號后，中斷當前任務來響應中斷請求。當異常發(fā)生時，CPU暫停當前的程序，先處理異常事件，然后再繼續(xù)執(zhí)行被異常打斷的程序。中斷與異常處理機制常用的中斷控制器有VIC（VectorInterruptController，向量中斷控制器）和GIC（GeneralInterruptController，通用中斷控制器）。LiteOS-A內(nèi)核支持的是ARM公司的Cortex-A/R系列的芯片，GIC是ARM公司給Cortex-A/R系列芯片提供的一個中斷控制器，類似Cortex-M中的NVIC。GIC控制器有4個版本V1-V4，V2版本是給ARMv7-A架構(gòu)使用的，比如Cortex-A5，Cortex-A7、Cortex-A9、Cortex-A15等。中斷與異常處理機制當GIC控制器接收到外部中斷信號以后匯報給ARM內(nèi)核，ARM內(nèi)核提供了四個信號給GIC來匯報中斷情況：VFIQ、VIRQ、FIQ和IRQ，如圖所示。中斷與異常處理機制4個信號含義如下：VFIQ：虛擬快速FIQVIRQ：虛擬外部IRQFIQ：快速中斷IRQIRQ：外部中斷IRQGIC控制器接收眾多的外部中斷，并對其進行處理，最終通過四個信號報給ARM內(nèi)核。中斷與異常處理的概念和機制LiteOS-A當前支持ARMv7-a指令集架構(gòu)，以ARMv7-a架構(gòu)為例，中斷和異常處理的入口為中斷向量表，中斷向量表包含各個中斷和異常處理的中斷向量，如表所示。中斷向量異常中斷名稱_exception_handlersresetvector復位osExceptUndeflnstrHd未定義的指令osExceptSwiHdl軟件中斷osExceptPrefetchAbortHdl預取指令中止osExceptDataAbortHdl數(shù)據(jù)訪問中止osExceptAddrAbortHd地址異常中止OslrqHandler外部中斷請求osExceptFiqHd快速中斷請求謝謝5.2.2中斷與異常處理接口與應用通過本節(jié)學習，您可以：了解中斷與異常處理接口說明與應用中斷與異常處理接口與應用OpenHarmonyLiteOS-A內(nèi)核的中斷模塊提供的接口跟LiteOS-M基本相同，包括創(chuàng)建中斷、刪除中斷、打開和關(guān)閉中斷等接口，如表所示。1.

中斷與異常處理管理接口功能分類接口名描述創(chuàng)建中斷LOS_HwiCreate中斷創(chuàng)建，注冊中斷號、中斷觸發(fā)模式、中斷優(yōu)先級、中斷處理程序。中斷被觸發(fā)時，會調(diào)用該中斷處理程序刪除中斷LOS_HwiDelete根據(jù)指定的中斷號，刪除中斷打開中斷LOS_IntUnLock打開當前處理器所有中斷響應關(guān)閉中斷LOS_IntLock關(guān)閉當前處理器所有中斷響應恢復中斷LOS_IntRestore與LOS_IntLock配套使用，恢復到使用LOS_IntLock關(guān)閉所有中斷之前的狀態(tài)中斷與異常處理接口與應用中斷管理的一般開發(fā)流程如下：（1）調(diào)用中斷創(chuàng)建接口LOS_HwiCreate創(chuàng)建中斷。（2）調(diào)用LOS_HwiDelete接口刪除指定中斷，此接口根據(jù)實際情況使用，判斷是否需要刪除中斷。2.中斷管理應用謝謝5.3.1進程管理通過本節(jié)學習，您可以：了解進程管理進程管理進程是系統(tǒng)資源管理的基本單元。OpenHarmonyLiteOS-A內(nèi)核提供的進程模塊主要用于實現(xiàn)用戶態(tài)進程的隔離，不涉及內(nèi)核態(tài)進程。進程模塊主要為用戶提供多個進程，實現(xiàn)了進程之間的切換和通信，幫助用戶管理業(yè)務程序流程。進程采用搶占式調(diào)度機制，采用高優(yōu)先級優(yōu)先加同優(yōu)先級時間片輪轉(zhuǎn)的調(diào)度算法。進程一共有32個優(yōu)先級（0-31），用戶進程可配置的優(yōu)先級有22個（10-31），最高優(yōu)先級為10，最低優(yōu)先級為31。高優(yōu)先級的進程可搶占低優(yōu)先級進程，低優(yōu)先級進程必須在高優(yōu)先級進程阻塞或結(jié)束后才能得到調(diào)度。每一個用戶態(tài)進程均擁有自己獨立的進程空間，相互之間不可見，實現(xiàn)進程間隔離。用戶態(tài)根進程init由內(nèi)核態(tài)創(chuàng)建，其它用戶態(tài)子進程均由init進程創(chuàng)建而來。1.

進程的概念進程管理進程有多種狀態(tài)，各狀態(tài)之間的關(guān)系如圖所示：2.進程狀態(tài)初始化（Init）：進程正在被創(chuàng)建。就緒態(tài)（Ready）：進程在就緒列表中，等待CPU調(diào)度。運行態(tài)（Running）：進程正在運行。阻塞態(tài)（Pending）：進程被阻塞掛起。本進程內(nèi)所有的線程均被阻塞時，進程被阻塞掛起。僵尸態(tài)（Zombies）：進程運行結(jié)束，等待父進程回收其控制塊資源。進程管理初始化→就緒態(tài)：進程創(chuàng)建或fork時，拿到對應進程控制塊后進入Init狀態(tài)，即進程初始化階段，當該階段完成后進程將被插入調(diào)度隊列，此時進程進入就緒狀態(tài)。就緒態(tài)→運行態(tài)：發(fā)生進程切換時，就緒列表中優(yōu)先級最高且獲得時間片的進程被執(zhí)行，從而進入運行態(tài)。若此時該進程中已無其它線程處于就緒態(tài)，則進程從就緒列表刪除，只處于運行態(tài)；若此時該進程中還有其它線程處于就緒態(tài)，則該進程依舊在就緒隊列，此時進程的就緒態(tài)和運行態(tài)共存，但對外呈現(xiàn)的進程狀態(tài)為運行態(tài)。

初始化就緒態(tài)阻塞態(tài)運行態(tài)僵尸態(tài)進程管理運行態(tài)→阻塞態(tài)：進程在最后一個線程轉(zhuǎn)為阻塞態(tài)時，進程內(nèi)所有的線程均處于阻塞態(tài)，此時進程同步進入阻塞態(tài)，然后發(fā)生進程切換。阻塞態(tài)→就緒態(tài)：阻塞進程內(nèi)的任意線程恢復就緒態(tài)時，進程被加入到就緒隊列，同步轉(zhuǎn)為就緒態(tài)。就緒態(tài)→阻塞態(tài)：進程內(nèi)的最后一個就緒態(tài)線程轉(zhuǎn)為阻塞態(tài)時，進程從就緒列表中刪除，進程由就緒態(tài)轉(zhuǎn)為阻塞態(tài)。

初始化就緒態(tài)阻塞態(tài)運行態(tài)僵尸態(tài)進程管理運行態(tài)→就緒態(tài)：有更高優(yōu)先級的進程創(chuàng)建或者恢復后，會發(fā)生進程調(diào)度，此刻就緒列表中最高優(yōu)先級進程變?yōu)檫\行態(tài)，那么原先運行的進程由運行態(tài)變?yōu)榫途w態(tài)。若進程的調(diào)度策略為LOS_SCHED_RR（時間片輪轉(zhuǎn)），且存在同一優(yōu)先級的另一個進程處于就緒態(tài)，則該進程的時間片消耗光之后，該進程由運行態(tài)轉(zhuǎn)為就緒態(tài)，另一個同優(yōu)先級的進程由就緒態(tài)轉(zhuǎn)為運行態(tài)。

初始化就緒態(tài)阻塞態(tài)運行態(tài)僵尸態(tài)進程管理運行態(tài)→僵尸態(tài)：當進程的主線程或所有線程運行結(jié)束后，進程由運行態(tài)轉(zhuǎn)為僵尸態(tài)，等待父進程回收資源。

初始化就緒態(tài)阻塞態(tài)運行態(tài)僵尸態(tài)進程管理進程管理主要是合理的分配各個進程使用CPU的時間。用戶態(tài)進程由Init進程分解而來，如圖所示。fork進程時會將父進程的進程虛擬內(nèi)存空間克隆到子進程，子進程實際運行時通過寫時復制機制將父進程的內(nèi)容按需復制到子進程的虛擬內(nèi)存空間。3.進程運行機制用戶態(tài)進程

多線程用戶態(tài)進程

多線程Init進程

多線程進程管理OpenHarmonyLiteOS-A內(nèi)核的進程管理模塊提供了進程組、用戶組、進程創(chuàng)建等接口。4.進程接口功能分類接口名接口描述獲取進程IDLOS_GetCurrProcessID獲取當前進程的進程ID進程組LOS_GetProcessGroupID獲取指定進程的進程組IDLOS_GetCurrProcessGroupID獲取當前進程的進程組ID用戶及用戶組LOS_GetUserID獲取當前進程的用戶IDLOS_GetGroupID獲取當前進程的用戶組IDLOS_CheckInGroups檢查指定用戶組ID是否在當前進程的用戶組內(nèi)進程管理功能分類接口名接口描述進度調(diào)度參數(shù)控制LOS_GetProcessScheduler獲取指定進程的調(diào)度策略LOS_SetProcessScheduler設置指定進程的調(diào)度參數(shù)，包括優(yōu)先級和調(diào)度策略LOS_SetProcessPriority設置進程優(yōu)先級LOS_GetProcessPriority獲取進程優(yōu)先級系統(tǒng)支持的最大進程數(shù)LOS_GetSystemProcessMaximum獲取系統(tǒng)支持的最大進程數(shù)目LOS_GetUsedPIDList獲得已使用的進程ID列表進程管理功能分類接口名接口描述創(chuàng)建進程LOS_Fork創(chuàng)建子進程等待進程LOS_Wait等待子進程結(jié)束并回收子進程LOS_Waitid等待相應ID的進程結(jié)束退出進程LOS_Exit退出進程謝謝5.3.2任務管理通過本節(jié)學習，您可以：了解任務管理任務管理從系統(tǒng)的角度看，任務Task是競爭系統(tǒng)資源的最小運行單元。任務可以使用或等待CPU、使用內(nèi)存空間等系統(tǒng)資源，并獨立于其它任務運行。OpenHarmony內(nèi)核中使用一個任務表示一個線程。OpenHarmony內(nèi)核中同優(yōu)先級進程內(nèi)的任務統(tǒng)一調(diào)度、運行。OpenHarmony內(nèi)核中的任務采用搶占式調(diào)度機制，同時支持時間片輪轉(zhuǎn)調(diào)度和FIFO調(diào)度方式。內(nèi)核的任務一共有32個優(yōu)先級（0-31），最高優(yōu)先級為0，最低優(yōu)先級為31。當前進程內(nèi)，高優(yōu)先級的任務可搶占低優(yōu)先級任務，低優(yōu)先級任務必須在高優(yōu)先級任務阻塞或結(jié)束后才能得到調(diào)度。1.

任務管理概念任務管理任務的各狀態(tài)如圖所示：

初始化就緒態(tài)阻塞態(tài)運行態(tài)退出初始化（Init）：任務正在被創(chuàng)建。就緒態(tài)（Ready）：任務在就緒隊列中，等待CPU調(diào)度。運行態(tài)（Running）：任務正在運行。阻塞態(tài)（Blocked）：任務被阻塞掛起。Blocked狀態(tài)包括：pending(因為鎖、事件、信號量等阻塞)、suspended（主動pend）、delay(延時阻塞)、pendtime(因為鎖、事件、信號量時間等超時等待)。退出態(tài)（Exit）：任務運行結(jié)束，等待父任務回收其控制塊資源。任務管理初始化→就緒態(tài)：任務創(chuàng)建拿到控制塊后為初始化階段(Init狀態(tài))，當任務初始化完成將任務插入調(diào)度隊列，此時任務進入就緒狀態(tài)。就緒態(tài)→運行態(tài)：任務創(chuàng)建后進入就緒態(tài)，發(fā)生任務切換時，就緒隊列中最高優(yōu)先級的任務被執(zhí)行，從而進入運行態(tài)，此刻該任務從就緒隊列中刪除。

初始化就緒態(tài)阻塞態(tài)運行態(tài)退出任務管理運行態(tài)→阻塞態(tài)：正在運行的任務發(fā)生阻塞（掛起、延時、讀信號量等）時，任務狀態(tài)由運行態(tài)變成阻塞態(tài)，然后發(fā)生任務切換，運行就緒隊列中剩余最高優(yōu)先級任務。阻塞態(tài)→就緒態(tài)：阻塞的任務被恢復后（任務恢復、延時時間超時、讀信號量超時或讀到信號量等），此時被恢復的任務會被加入就緒隊列，從而由阻塞態(tài)變成就緒態(tài)。

初始化就緒態(tài)阻塞態(tài)運行態(tài)退出任務管理就緒態(tài)→阻塞態(tài)：任務也有可能在就緒態(tài)時被阻塞（掛起），此時任務狀態(tài)會由就緒態(tài)轉(zhuǎn)變?yōu)樽枞麘B(tài)，該任務從就緒隊列中刪除，不會參與任務調(diào)度，直到該任務被恢復。運行態(tài)→就緒態(tài)：有更高優(yōu)先級任務創(chuàng)建或者恢復后，會發(fā)生任務調(diào)度，此刻就緒隊列中最高優(yōu)先級任務變?yōu)檫\行態(tài)，那么原先運行的任務由運行態(tài)變?yōu)榫途w態(tài)，并加入就緒隊列中。

初始化就緒態(tài)阻塞態(tài)運行態(tài)退出任務管理運行態(tài)→退出態(tài)：運行中的任務運行結(jié)束，任務狀態(tài)由運行態(tài)變?yōu)橥顺鰬B(tài)。

初始化就緒態(tài)阻塞態(tài)運行態(tài)退出任務管理OpenHarmonyLiteOS-A內(nèi)核的任務管理模塊提供了創(chuàng)建任務、刪除任務、控制任務狀態(tài)、獲取任務信息等幾種功能，具體如表所示。2.任務管理接口功能分類接口名接口描述任務的創(chuàng)建和刪除

LOS_TaskCreate創(chuàng)建任務，若所創(chuàng)建任務的優(yōu)先級比當前的運行的任務優(yōu)先級高且任務調(diào)度沒有鎖定，則該任務將被調(diào)度進入運行態(tài)LOS_TaskCreateOnly創(chuàng)建任務并阻塞，任務恢復前不會將其加入就緒隊列中LOS_TaskDelete刪除指定的任務，回收其任務控制塊和任務棧所消耗的資源任務的狀態(tài)控制

LOS_TaskResume恢復掛起的任務LOS_TaskSuspend掛起指定的任務，該任務將從就緒任務隊列中移除LOS_TaskJoin阻塞當前任務，等待指定任務運行結(jié)束并回收其資源LOS_TaskDetach修改任務的joinable屬性為detach屬性，detach屬性的任務運行結(jié)束會自動回收任務控制塊資源LOS_TaskDelay延遲當前任務的執(zhí)行，在延后指定的時間（tick數(shù)）后可以被調(diào)度LOS_TaskYield將當前任務從具有相同優(yōu)先級的任務隊列，移動到就緒任務隊列的末尾任務管理功能分類接口名接口描述任務調(diào)度

LOS_TaskLock鎖定任務調(diào)度，阻止任務切換LOS_TaskUnlock解鎖任務調(diào)度。通過該接口可以使任務鎖數(shù)量減1，若任務多次加鎖，那么任務調(diào)度在鎖數(shù)量減為0時才會完全解鎖LOS_GetTaskScheduler獲取指定任務的調(diào)度策略LOS_SetTaskScheduler設置指定任務的調(diào)度參數(shù)，包括優(yōu)先級和調(diào)度策略LOS_Schedule觸發(fā)主動的任務調(diào)度任務信息獲取

LOS_CurTaskIDGet獲取當前任務的IDLOS_TaskInfoGet獲取指定任務的信息LOS_GetSystemTaskMaximum獲取系統(tǒng)支持的最大任務數(shù)任務優(yōu)先級

LOS_CurTaskPriSet設置當前正在運行的任務的優(yōu)先級LOS_TaskPriSet設置指定任務的優(yōu)先級LOS_TaskPriGet獲取指定任務的優(yōu)先級任務綁核操作

LOS_TaskCpuAffiSet綁定指定任務到指定CPU上運行，僅在多核下使用LOS_TaskCpuAffiGet獲取指定任務的綁核信息，僅在多核下使用任務管理任務管理的一般開發(fā)流程如下：（1）通過LOS_TaskCreate創(chuàng)建一個任務。指定任務的執(zhí)行入口函數(shù)指定任務名指定任務的棧大小指定任務的優(yōu)先級（2）任務參與調(diào)度運行，執(zhí)行用戶指定的業(yè)務代碼。（3）任務執(zhí)行結(jié)束。3.任務管理應用謝謝5.3.3調(diào)度器通過本節(jié)學習，您可以：了解調(diào)度器調(diào)度器調(diào)度器（scheduler）是一個操作系統(tǒng)的核心部分，是CPU時間的管理員，負責選擇最適合的就緒進程來執(zhí)行。1.

調(diào)度器概念周期性調(diào)度器CPU上下文切換主調(diào)度器選擇進程調(diào)度器類進程調(diào)度器主要完成兩件事：選擇某些就緒進程來執(zhí)行。打斷某些執(zhí)行的進程讓他們變?yōu)榫途w態(tài)調(diào)度器主調(diào)度器：通過調(diào)用schedule()函數(shù)來完成進程的選擇和切換。周期性調(diào)度器：根據(jù)頻率自動調(diào)用scheduler_tick函數(shù)，根據(jù)進程運行時間觸發(fā)調(diào)度。上下文切換：主要做兩個事情，切換地址空間、切換寄存器和?？臻g。調(diào)度器類：每個調(diào)度器都有一個優(yōu)先級，它會按照優(yōu)先級順序遍歷調(diào)度類，擁有一個可執(zhí)行進程的最高優(yōu)先級的調(diào)度器類勝出，去選擇下面要執(zhí)行的那一個程序。周期性調(diào)度器CPU上下文切換主調(diào)度器選擇進程調(diào)度器類進程調(diào)度器2.調(diào)度器運行機制OpenHarmony在系統(tǒng)啟動內(nèi)核初始化之后開始調(diào)度。系統(tǒng)根據(jù)進程和線程的優(yōu)先級及線程的時間片消耗情況選擇最優(yōu)的線程進行調(diào)度運行。線程一旦調(diào)度到就會從調(diào)度隊列上刪除，線程在運行過程中發(fā)生阻塞，會被加入到對應的阻塞隊列中并觸發(fā)一次調(diào)度，調(diào)度其它線程運行。如果調(diào)度隊列上沒有可以調(diào)度的線程，則系統(tǒng)就會選擇KIdle進程的線程進行調(diào)度運行。調(diào)度器OpenHarmonyLiteOS-A內(nèi)核的調(diào)度器模塊提供了調(diào)度相關(guān)的接口。3.調(diào)度器接口功能分類接口名稱描述觸發(fā)系統(tǒng)調(diào)度LOS_Schedule觸發(fā)系統(tǒng)調(diào)度LOS_GetTaskScheduler獲取指定任務的調(diào)度策略LOS_SetTaskScheduler設置指定任務的調(diào)度策略LOS_GetProcessScheduler獲取指定進程的調(diào)度策略LOS_SetProcessScheduler設置指定進程的調(diào)度參數(shù)，包括優(yōu)先級和調(diào)度策略調(diào)度器進程管理的應用，具體代碼如下：

#include<stdio.h>

#include"osal_thread.h"

/**

*@brief輸出“helloohos”函數(shù)

*@paramvoid

*@retvalvoid

*/

voidTask_hello_ohos(void)

{

while(1)

{

printf("Helloohos!!!\r\n");

}

}

/**

*@brief任務創(chuàng)建函數(shù)

*@paramvoid

*@retvalvoid

*/

調(diào)度器

intmain(intargc,char**argv)

{

structOsalThreadtask_ohos;//ohos任務ID

structOsalThreadParamtaskoh;//定義ohos任務結(jié)構(gòu)體

taskoh.stackSize=1028;//任務堆棧

="Task_hello_ohos";//任務名稱

taskoh.priority=OSAL_THREAD_PRI_LOW;//任務優(yōu)先級

/**創(chuàng)建任務**/

if(OsalThreadCreate(&task_ohos,Task_hello_ohos,NULL)!=HDF_SUCCESS)

{

printf("task_ohoscreateFailed!\r\n");

}

printf("task_ohoscreatesuccessful!\r\n");

if(OsalThreadStart(&task_ohos,&taskoh)!=HDF_SUCCESS)

{

printf("task_ohosstartFailed!\r\n");

}

printf("task_ohosstartsuccessful!\r\n");}調(diào)度器運行結(jié)果如下：謝謝6.1.1

HDF驅(qū)動框架介紹通過本節(jié)學習，您可以：了解HDF驅(qū)動框架HDF驅(qū)動框架介紹HDF驅(qū)動框架介紹：HDF驅(qū)動架構(gòu)采用C語言面向?qū)ο缶幊棠Ｐ蜆?gòu)建，通過平臺解耦、內(nèi)核解耦，來達到兼容不同內(nèi)核，統(tǒng)一平臺底座的目的，從而幫助開發(fā)者實現(xiàn)驅(qū)動一次開發(fā)，多系統(tǒng)部署的效果。HDF驅(qū)動框架介紹HDF驅(qū)動框架架構(gòu)組成：OSAL：操作系統(tǒng)抽象層（OperatingSystemAbstractionLayer），提供統(tǒng)一封裝的內(nèi)核操作相關(guān)接口，屏蔽不同系統(tǒng)操作差異，包含內(nèi)存、鎖、線程、信號量等接口。HDF驅(qū)動框架介紹HDF驅(qū)動框架架構(gòu)組成：1.HDF驅(qū)動基礎(chǔ)框架：提供統(tǒng)一的硬件資源管理，驅(qū)動加載管理以及設備節(jié)點管理等功能。驅(qū)動框架采用的是主從模式設計，由DeviceManager和DeviceHost組成。HDF驅(qū)動框架介紹HDF驅(qū)動框架架構(gòu)組成：2.驅(qū)動程序：實現(xiàn)驅(qū)動具體的功能，每個驅(qū)動由一個或者多個驅(qū)動程序組成，每個驅(qū)動程序都對應著一個DriverEntry。HDF驅(qū)動框架介紹HDF驅(qū)動框架架構(gòu)組成：3.驅(qū)動配置文件.hcs：主要由設備信息（DeviceInformation）和設備資源（DeviceResource）組成。HDF驅(qū)動框架介紹HDF驅(qū)動框架架構(gòu)組成：4.驅(qū)動接口：HDI（HardwareDriverinterface，硬件設備接口）提供標準化的接口定義和實現(xiàn)，驅(qū)動框架提供IOService和IODispatcher機制，使得不同部署形態(tài)下驅(qū)動接口趨于形式一致。謝謝6.1.2HDF驅(qū)動模型介紹通過本節(jié)學習，您可以：了解HDF驅(qū)動模型HDF驅(qū)動模型介紹HDF設備驅(qū)動模型的組成：Host（設備容器）、Device（設備）、DeviceNode（設備節(jié)點）、Driver（驅(qū)動程序）。HDF框架將一類設備驅(qū)動放在同一個Host里面，用于管理一組設備的啟動加載等過程。Device對應一個真實的物理設備。DeviceNode是設備的一個部件，Device至少有一個DeviceNode。每個DeviceNode可以發(fā)布一個設備服務。每個DevicdNode唯一對應一個驅(qū)動，實現(xiàn)和硬件的功能交互。HDF驅(qū)動模型介紹在劃分Host時，驅(qū)動程序是部署在一個Host還是部署在不同的Host，主要考慮驅(qū)動程序之間是否存在耦合性，如果兩個驅(qū)動程序之間存在依賴，可以考慮將這部分驅(qū)動程序部署在一個Host里面。Host有兩種屬性：hostName，priority屬性取值描述hostName字符串設備集合的名稱。Priority整數(shù)，0-200設備集合的優(yōu)先級。數(shù)值越大，優(yōu)先級越低；如果優(yōu)先級相同，則不能保證加載順序。HDF驅(qū)動模型介紹HDF驅(qū)動框架給DeviceNode設備節(jié)點定義的屬性：屬性取值描述moduleName字符串每個設備節(jié)點所對應的驅(qū)動程序被稱為一個module，每一個module都有一個moduleName。preload整數(shù)驅(qū)動被HDF加載的方式Priority整數(shù)，0-200驅(qū)動的優(yōu)先級。數(shù)值越大，優(yōu)先級越低；如果優(yōu)先級相同，則不能保證加載順序。serviceNamen字符串驅(qū)動對外發(fā)布的服務的名稱，必須唯一。policy整數(shù)驅(qū)動對外發(fā)布服務的策略。permission整數(shù)設備節(jié)點的讀寫權(quán)限，一般采用以0為前綴的8進制整數(shù)，類似于linux的文件權(quán)限的概念。deviceMatchAttr字符串用于匹配設備節(jié)點的自定義屬性。HDF驅(qū)動模型介紹驅(qū)動的加載方式如下：

typedef

enum{

DEVICE_PRELOAD_ENABLE=0,

DEVICE_PRELOAD_ENABLE_STEP2,

DEVICE_PRELOAD_DISABLE,

DEVICE_PRELOAD_INVALID

}DevicePreload;preload字段配置為0（DEVICE_PRELOAD_ENABLE），則系統(tǒng)啟動過程中默認加載。preload字段配置為1（DEVICE_PRELOAD_ENABLE_STEP2），當系統(tǒng)支持快速啟動的時候，則在系統(tǒng)完成之后再加載這一類驅(qū)動。preload字段配置為2（DEVICE_PRELOAD_DISABLE），則系統(tǒng)啟動過程中默認不加載。謝謝6.1.3HDF驅(qū)動開發(fā)步驟通過本節(jié)學習，您可以：了解HDF驅(qū)動開發(fā)步驟HDF驅(qū)動開發(fā)步驟HDF框架的驅(qū)動開發(fā)的組成部分：驅(qū)動實現(xiàn)、驅(qū)動編譯腳本編寫和驅(qū)動配置。1.驅(qū)動實現(xiàn)：驅(qū)動實現(xiàn)包含驅(qū)動業(yè)務代碼實現(xiàn)和驅(qū)動入口注冊，具體寫法如下：（1）驅(qū)動業(yè)務代碼模板

#include"hdf_device_desc.h"http://HDF框架對驅(qū)動開發(fā)相關(guān)能力接口的頭文件

#include"hdf_log.h"http://HDF框架提供的日志接口頭文件

#defineHDF_LOG_TAGtest_driver//打印日志所包含的標簽，如果不定義則用默認定義的HDF_TAG標簽。

//將驅(qū)動對外提供的服務能力接口綁定到HDF框架。

int32_tHdfTestDriverBind(structHdfDeviceObject*deviceObject){

HDF_LOGD("Testdriverbindsuccess");

returnHDF_SUCCESS;

}

//驅(qū)動自身業(yè)務初始化的接口

int32_tHdfTestDriverInit(structHdfDeviceObject*deviceObject){

HDF_LOGD("TestdriverInitsuccess");

returnHDF_SUCCESS;

}

//驅(qū)動資源釋放的接口

voidHdfTestDriverRelease(structHdfDeviceObject*deviceObject){

HDF_LOGD("Testdriverreleasesuccess");

return;

}HDF驅(qū)動開發(fā)步驟（2）驅(qū)動入口注冊到HDF框架

structHdfDriverEntryg_testDriverEntry={

.moduleVersion=1,

.moduleName="test_driver",

.Bind=HdfTestDriverBind,

.Init=HdfTestDriverInit,

.Release=HdfTestDriverRelease,

};

//調(diào)用HDF_INIT將驅(qū)動入口注冊到HDF框架中。在加載驅(qū)動時HDF框架會先調(diào)用Bind函數(shù)，再調(diào)用Init函數(shù)加載該驅(qū)動；當Init調(diào)用異常時，HDF框架會調(diào)用Release釋放驅(qū)動資源并退出。

HDF_INIT(g_testDriverEntry);驅(qū)動注冊，就是實例化驅(qū)動入口，驅(qū)動入口必須為HdfDriverEntry（在hdf_device_desc.h中定義）類型的全局變量，且moduleName要和device_info.hcs中保持一致。HDF框架會將所有加載的驅(qū)動的HdfDriverEntry對象首地址匯總，形成一個類似數(shù)組的段地址空間，方便上層調(diào)用。HDF驅(qū)動開發(fā)步驟2.驅(qū)動編譯腳本編寫添加模塊BUILD.gn把新增模塊的BUILD.gn所在的目錄添加到上一級BUILD.gn文件中

import("http://drivers/adapter/khdf/liteos/hdf.gni")

hdf_driver("hdf_led"){

sources=[

"led.c",#此處為點燈實驗，根據(jù)實驗進行修改

]

include_dirs=[

"http://device/st/drivers/module_driver/Module_Common/inc/",

]}

group("drivers"){

deps=[

"led",#新增模塊BUILD.gn的名稱，根據(jù)實驗進行修改

]

}HDF驅(qū)動開發(fā)步驟3.驅(qū)動配置驅(qū)動配置包含兩部分：HDF框架定義的驅(qū)動設備描述和驅(qū)動的私有配置信息。（1）驅(qū)動設備描述HDF框架加載驅(qū)動所需要的信息來源于HDF框架定義的驅(qū)動設備描述，因此基于HDF框架開發(fā)的驅(qū)動必須要在HDF框架定義的device_info.hcs配置文件中添加對應的設備描述。

root{

device_info{

match_attr="hdf_manager";HDF驅(qū)動開發(fā)步驟

templatehost{//host模板，繼承該模板的節(jié)點（如下test_host）如果使用模板中的默認值，則節(jié)點字段可以缺省。

hostName="";

priority=100;

templatedevice{

templatedeviceNode{

policy=0;

priority=100;

preload=0;

permission=0664;

moduleName="";

serviceName="";

deviceMatchAttr="";

}

}

}HDF驅(qū)動開發(fā)步驟

platform::host{

hostName="platform_host";//host名稱，host節(jié)點是用來存放某一類驅(qū)動的容器。

priority=50;//host啟動優(yōu)先級（0-200），值越大優(yōu)先級越低，建議默認配100，優(yōu)先級相同則不保證host的加載順序。

device_led::device{//led設備節(jié)點

device0::deviceNode{//led驅(qū)動的DeviceNode節(jié)點

policy=2;//policy字段是驅(qū)動服務發(fā)布的策略

priority=200;//驅(qū)動啟動優(yōu)先級（0-200），值越大優(yōu)先級越低，建議默認配100，優(yōu)先級相同則不保證device的加載順序

preload=0;//驅(qū)動按需加載字段

permission=0777;//驅(qū)動創(chuàng)建設備節(jié)點權(quán)限

moduleName="HDF_LED";//驅(qū)動名稱，該字段的值必須和驅(qū)動入口結(jié)構(gòu)的moduleName值一致

serviceName="hdf_led";//驅(qū)動對外發(fā)布服務的名稱，必須唯一

deviceMatchAttr="st_stm32mp157_led";//驅(qū)動私有數(shù)據(jù)匹配的關(guān)鍵字，必須和驅(qū)動私有數(shù)據(jù)配置表中的match_attr值相等

}

}

}

}}HDF驅(qū)動開發(fā)步驟（2）驅(qū)動私有配置信息如果驅(qū)動有私有配置，則可以添加一個驅(qū)動的配置文件，用來填寫一些驅(qū)動的默認配置信息。HDF框架在加載驅(qū)動的時候，會將對應的配置信息獲取并保存在HdfDeviceObject中的property里面，通過Bind和Init傳遞給驅(qū)動。驅(qū)動的配置信息示例如下：配置信息定義之后，需要將該配置文件添加到板級配置入口文件hdf.hcs，示例如下：

root{

LedDriverConfig{

led_gpio_num=13;

match_attr="st_stm32mp157_led";//該字段的值必須和device_info.hcs中的deviceMatchAttr值一致

}

}

#include"device_info/device_info.hcs"

#include"led/led_config.hcs"

謝謝6.2.1驅(qū)動服務介紹通過本節(jié)學習，您可以：了解驅(qū)動服務介紹驅(qū)動服務介紹當驅(qū)動需要以接口的形式對外提供能力時，可以使用HDF框架的驅(qū)動服務管理能力。驅(qū)動服務是HDF驅(qū)動設備對外提供能力的對象，由HDF框架統(tǒng)一管理。驅(qū)動服務管理主要包含驅(qū)動服務的發(fā)布和獲取。1.驅(qū)動服務的發(fā)布：HDF框架定義了驅(qū)動對外發(fā)布服務的策略，由配置文件中的policy字段來控制，policy字段的取值范圍以及含義如下：

typedef

enum{

SERVICE_POLICY_NONE=0,//驅(qū)動不提供服務

SERVICE_POLICY_PUBLIC=1,//驅(qū)動對內(nèi)核態(tài)發(fā)布服務

SERVICE_POLICY_CAPACITY=2,//驅(qū)動對內(nèi)核態(tài)和用戶態(tài)都發(fā)布服務

SERVICE_POLICY_FRIENDLY=3,//驅(qū)動服務不對外發(fā)布服務，但可以被訂閱

SERVICE_POLICY_PRIVATE=4,//驅(qū)動私有服務不對外發(fā)布服務，也不能被訂閱

SERVICE_POLICY_INVALID//錯誤的服務策略

}ServicePolicy;驅(qū)動服務介紹2.驅(qū)動服務的獲?。候?qū)動服務的獲取有兩種方式：通過HDF接口直接獲?。寒斆鞔_驅(qū)動已經(jīng)加載完成時，獲取該驅(qū)動的服務可以通過HDF框架提供的能力接口直接獲取。通過HDF提供的訂閱機制獲?。寒攦?nèi)核態(tài)對驅(qū)動（同一個host）加載的時機不感知時，可以通過HDF框架提供的閱機

制來訂閱該驅(qū)動，當該驅(qū)動加載完成時，HDF框架會將被訂閱的驅(qū)動服務發(fā)布給訂閱者。謝謝6.2.2驅(qū)動服務管理開發(fā)通過本節(jié)學習，您可以：了解驅(qū)動服務管理開發(fā)驅(qū)動服務管理開發(fā)1.驅(qū)動服務管理接口針對驅(qū)動服務管理功能，HDF框架開放了部分接口給開發(fā)者調(diào)用。方法描述int32_t(*Bind)(structHdfDeviceObject*deviceObject);需要驅(qū)動開發(fā)者實現(xiàn)Bind函數(shù)，將自己的服務接口綁定到HDF框架中conststructHdfObject*DevSvcManagerClntGetService(constchar*svcName);獲取驅(qū)動的服務intHdfDeviceSubscribeService(structHdfDeviceObject*deviceObject,constchar*serviceName,structSubscriberCallbackcallback);訂閱驅(qū)動的服務驅(qū)動服務管理開發(fā)2.驅(qū)動服務管理開發(fā)步驟（1）驅(qū)動服務的編寫驅(qū)動服務管理開發(fā)的第一步是定義驅(qū)動的服務接口。

//驅(qū)動服務結(jié)構(gòu)的定義

structITestDriverService{

structIDeviceIoServiceioService;//服務結(jié)構(gòu)的首個成員必須是IDeviceIoService類型的成員

int32_t(*ServiceA)(void);//驅(qū)動的第一個服務接口

int32_t(*ServiceB)(uint32_tinputCode);//驅(qū)動的第二個服務接口，有多個可以依次往下累加

};

驅(qū)動服務接口的實現(xiàn)

int32_tTestDriverServiceA(void)

{

//驅(qū)動開發(fā)者實現(xiàn)業(yè)務邏輯

returnHDF_SUCCESS;

}

int32_tTestDriverServiceB(uint32_tinputCode)

{

//驅(qū)動開發(fā)者實現(xiàn)業(yè)務邏輯

returnHDF_SUCCESS;

}驅(qū)動服務管理開發(fā)（2）驅(qū)動服務綁定驅(qū)動服務綁定到HDF框架中，實現(xiàn)HdfDriverEntry中的Bind指針函數(shù)。

int32_tTestDriverBind(structHdfDeviceObject*deviceObject)

{

//deviceObject為HDF框架給每一個驅(qū)動創(chuàng)建的設備對象，用來保存設備相關(guān)的私有數(shù)據(jù)和服務接口

if(deviceObject==NULL){

HDF_LOGE("Testdeviceobjectisnull!");

returnHDF_FAILURE;

}

static

structITestDriverServicetestDriverA={

.ServiceA=TestDriverServiceA,

.ServiceB=TestDriverServiceB,

};

deviceObject->service=&testDriverA.ioService;

returnHDF_SUCCESS;

}驅(qū)動服務管理開發(fā)（3）驅(qū)動服務獲取通過HDF接口直接獲?。?/p>

const

structITestDriverService*testService=

(const

structITestDriverService*)DevSvcManagerClntGetService("test_driver");

if(testService==NULL){

returnHDF_FAILURE;

}

testService->ServiceA();testService->ServiceB(5);驅(qū)動服務管理開發(fā)

//object為訂閱者的私有數(shù)據(jù)，service為被訂閱的服務對象

int32_tTestDriverSubCallBack(structHdfDeviceObject*deviceObject,const

structHdfObject*service)

{

const

structITestDriverService*testService=

(const

structITestDriverService*)service;

if(testService==NULL){

returnHDF_FAILURE;

}

testService->ServiceA();

testService->ServiceB(5);

}通過HDF提供的訂閱機制獲?。盒枰帉懹嗛喕卣{(diào)函數(shù)，當被訂閱的驅(qū)動加載完成后，HDF框架會將被訂閱驅(qū)動的服務發(fā)布給訂閱者，通過這個回調(diào)函數(shù)給訂閱者使用。驅(qū)動服務管理開發(fā)

//訂閱過程的實現(xiàn)

int32_tTestDriverInit(structHdfDeviceObject*deviceObject)

{

if(deviceObject==NULL){

HDF_LOGE("Testdriverinitfailed,deviceObjectisnull!");

returnHDF_FAILURE;

}

structSubscriberCallbackcallBack;

callBack.deviceObject=deviceObject;

callBack.OnServiceConnected=TestDriverSubCallBack;

int32_tret=HdfDeviceSubscribeService(deviceObject,"test_driver",callBack);

if(ret!=HDF_SUCCESS){

HDF_LOGE("Testdriversubscribetestdriverfailed!");

}

returnret;}謝謝6.3.1驅(qū)動消息機制管理通過本節(jié)學習，您可以：了解驅(qū)動消息機制管理驅(qū)動消息機制管理鴻蒙系統(tǒng)的的HDF框架提供了統(tǒng)一的驅(qū)動消息機制。當用戶態(tài)應用和內(nèi)核態(tài)驅(qū)動需要交互時，可以使用HDF框架的消息機制來實現(xiàn)。用戶態(tài)：指應用程序運行的環(huán)境，應用程序在用戶態(tài)下運行，可以訪問系統(tǒng)資源，如文件、網(wǎng)絡等。用戶態(tài)下的應用程序運行在受限的環(huán)境中，不能直接訪問系統(tǒng)硬件資源，必須通過系統(tǒng)調(diào)用來請求內(nèi)核提供服務。內(nèi)核態(tài)：指操作系統(tǒng)內(nèi)核運行的環(huán)境，在操作系統(tǒng)啟動時，內(nèi)核被加載到內(nèi)存中，并開始執(zhí)行。消息機制的功能有以下兩種：用戶態(tài)應用發(fā)送消息到驅(qū)動。用戶態(tài)應用接收驅(qū)動主動上報事件。驅(qū)動消息機制管理消息機制的接口：接口描述structHdfIoService*HdfIoServiceBind(constchar*serviceName)用戶態(tài)獲取驅(qū)動的服務，獲取該服務之后通過服務中的Dispatch方法向驅(qū)動發(fā)送消息voidHdfIoServiceRecycle(structHdfIoService*service);獲取驅(qū)動的服務intHdfDeviceRegisterEventListener(structHdfIoService*target,structHdfDevEventlistener*listener);用戶態(tài)程序注冊接收驅(qū)動上報事件的操作方法intHdfDeviceSendEvent(structHdfDeviceObject*deviceObject,uint32_tid,structHdfSBuf*data);驅(qū)動主動上報事件接口謝謝6.3.2驅(qū)動消息機制開發(fā)通過本節(jié)學習，您可以：了解驅(qū)動消息機制開發(fā)驅(qū)動消息機制開發(fā)驅(qū)動消息機制的開發(fā)步驟：1.修改服務策略policy字段將驅(qū)動配置信息中服務策略policy字段設置為2。

device_test::Device{

policy=2;

...

}2.配置驅(qū)動信息中的服務設備節(jié)點權(quán)限配置驅(qū)動信息中的服務設備節(jié)點權(quán)限（permission字段）是框架給驅(qū)動創(chuàng)建設備節(jié)點的權(quán)限，默認是0666，驅(qū)動開發(fā)者根據(jù)驅(qū)動的實際使用場景配置驅(qū)動設備節(jié)點的權(quán)限。驅(qū)動消息機制開發(fā)3.實現(xiàn)Dispatch方法在服務實現(xiàn)過程中，實現(xiàn)服務基類成員IDeviceIoService中的Dispatch方法。

//Dispatch是用來處理用戶態(tài)發(fā)下來的消息

int32_tTestDriverDispatch(structHdfDeviceIoClient*device,intcmdCode,structHdfSBuf*data,structHdfSBuf*reply){

HDF_LOGE("testdriverliteAdispatch");

returnHDF_SUCCESS;

}

int32_tTestDriverBind(structHdfDeviceObject*device){

HDF_LOGE("testforliteostestdriverAOpen!");

if(device==NULL){

HDF_LOGE("testforliteostestdriverAOpenfailed!");

returnHDF_FAILURE;

}

static

structITestDriverServicetestDriverA={

.ioService.Dispatch=TestDriverDispatch,

.ServiceA=TestDriverServiceA,

.ServiceB=TestDriverServiceB,

};

device->service=(structIDeviceIoService*)(&testDriverA);

returnHDF_SUCCESS;}驅(qū)動消息機制開發(fā)4.定義cmd類型驅(qū)動定義消息處理函數(shù)中的cmd類型。5.獲取服務接口并發(fā)送消息用戶態(tài)獲取服務接口并發(fā)送消息到驅(qū)動。#defineTEST_WRITE_READ1//讀寫操作碼1

intSendMsg(const

char*testMsg)

{

if(testMsg==NULL){

HDF_LOGE("testmsgisnull");

returnHDF_FAILURE;

}

structHdfIoService*serv=HdfIoServiceBind("test_driver");

if(serv==NULL){

HDF_LOGE("failtogetservice");

returnHDF_FAILURE;}驅(qū)動消息機制開發(fā)

structHdfSBuf*data=HdfSBufObtainDefaultSize();

if(data==NULL){HDF_LOGE("failtoobtainsbufdata");

returnHDF_FAILURE;

}

structHdfSBuf*reply=HdfSBufObtainDefaultSize();

if(reply==NULL){HDF_LOGE("failtoobtainsbufreply");

ret=HDF_DEV_ERR_NO_MEMORY;

gotoout;

}

if(!HdfSbufWriteString(data,testMsg)){HDF_LOGE("failtowritesbuf");

ret=HDF_FAILURE;

gotoout;

}

intret=serv->dispatcher->Dispatch(&serv->object,TEST_WRITE_READ,data,reply);

if(ret!=HDF_SUCCESS){HDF_LOGE("failtosendservicecall");

gotoout;

}

out:

HdfSBufRecycle(data);

HdfSBufRecycle(reply);

HdfIoServiceRecycle(serv);

returnret;}驅(qū)動消息機制開發(fā)6.用戶態(tài)接收驅(qū)動上報的消息用戶態(tài)編寫驅(qū)動上報消息的處理函數(shù)。

static

intOnDevEventReceived(void*priv,uint32_tid,structHdfSBuf*data)

{

OsalTimespectime;

OsalGetTime(&time);

HDF_LOGE("%sreceivedeventat%llu.%llu",(char*)priv,time.sec,time.usec);

const

char*string=HdfSbufReadString(data);

if(string==NULL){

HDF_LOGE("failtoreadstringineve