之前介紹的電源管理機(jī)制基本都是在Linux中實(shí)現(xiàn)的，可以看到很復(fù)雜，各種框架，明明一個(gè)操作非要轉(zhuǎn)來轉(zhuǎn)去，而且在內(nèi)核里面實(shí)現(xiàn)，跟內(nèi)核的各種框架又糾纏不清，什么consumer、Framework、provider框架亂亂的。

就不能搞成最簡單的CS構(gòu)架，一個(gè)Client和一個(gè)Server就搞定了，不需要什么框架，也不需要跟各種程序混到一塊去，就像上圖的一個(gè)問題：去飯店吃飯是客戶端還是服務(wù)端？

這里重點(diǎn)以QNX為例，介紹下微內(nèi)核中的電源管理的特點(diǎn)：

電源管理作為一個(gè)Server在用戶層，算一個(gè)APP

電源管理服務(wù)的對象Client：電源敏感APP、驅(qū)動(dòng)APP、電源監(jiān)控APP

Client和Server之間通過IPC通信，約定好通信的報(bào)文

1. QNX電源管理框架

電源管理服務(wù)可以：

可以控制各個(gè)設(shè)備包括CPU的電源狀態(tài)

一組電源管理服務(wù)，用于實(shí)現(xiàn)電源管理策略，可以管理應(yīng)用APP即設(shè)備硬件驅(qū)動(dòng)APP、電源敏感APP、電源監(jiān)控APP

電源管理架構(gòu)的主要組件是：

實(shí)施系統(tǒng)電源管理策略的電源管理服務(wù)

與電源管理器交互以根據(jù)系統(tǒng)策略調(diào)整功率級別的設(shè)備驅(qū)動(dòng)程序

電源監(jiān)控應(yīng)用程序——可以提供電源管理策略使用的輸入事件或數(shù)據(jù)

功率敏感應(yīng)用程序——可能會收到電源模式更改的通知。

QNX中一切都是文件，設(shè)備也是組織為文件層級，對設(shè)備的電源管理操作就是操作文件節(jié)點(diǎn)，例如上圖中。

電源管理狀態(tài)：

對于設(shè)備只定義了四種，簡單好管理。

Active：表示從用戶的角度來看實(shí)體是可操作的。

Idle：表示實(shí)體部分供電；并非所有功能都可操作。從用戶的角度來看，實(shí)體是可操作的，并在使用時(shí)轉(zhuǎn)換為*活動(dòng)*模式。

Standby：表示實(shí)體部分供電；只有有限的功能是可操作的，例如實(shí)現(xiàn)喚醒事件。從用戶的角度來看，該實(shí)體是不可操作的。

Off：指示實(shí)體已斷電且不可操作。

對于系統(tǒng)可以多定義一些電源層級，用來進(jìn)入不同級別的節(jié)電狀態(tài)，從而滿足多種需要。例如上圖中的車載遠(yuǎn)程信息處理系統(tǒng)的不同電源模式。

上圖顯示電源管理策略通過在空閑、待機(jī)（睡眠）或關(guān)機(jī)狀態(tài)之間轉(zhuǎn)換來逐步關(guān)閉設(shè)備。這用于限制從電池汲取的待機(jī)電流在點(diǎn)火裝置關(guān)閉時(shí)逐漸下降。該系統(tǒng)還可以隨時(shí)準(zhǔn)備在短時(shí)間內(nèi)啟動(dòng)。例如，實(shí)時(shí)時(shí)鐘 (RTC) 可用于定時(shí)喚醒 CPU 休眠模式。

當(dāng)汽車熄火后，像CPU、SDRAM、RF、RTC等設(shè)備不能立即斷電，因?yàn)镃PU、SDRAM是保持系統(tǒng)處于一個(gè)運(yùn)行狀態(tài)，而RF、RTC是系統(tǒng)喚醒源。

總結(jié)如下：

Power Manager Server初始化先調(diào)用power manager server的init()初始化命名空間，及power manager server提供的resource manager接口；調(diào)用start()初始化處理client請求的thread；觸發(fā)各個(gè)device driver or service啟動(dòng)；啟動(dòng)其他client：system monitoring apps， Power sensitive apps；

各個(gè)device driver or service啟動(dòng)過程中會向power manager server注冊

System monitoring apps 中的關(guān)火檢測線程檢測到關(guān)火事件，則將當(dāng)前的點(diǎn)火系統(tǒng)為off的狀態(tài)作為屬性發(fā)送給power manager；Power manager得知system monitor app 匯報(bào)了點(diǎn)火系統(tǒng)關(guān)閉的，會執(zhí)行相應(yīng)的電源管理策略，切換當(dāng)前電源模式；將Active1 Idle; 切換電源模式具體操作：對Audio、Video設(shè)備執(zhí)行電源模式切換，此操作為異步操作。

Audio、Video設(shè)備驅(qū)動(dòng)內(nèi)部執(zhí)行電源模式切換：Active->Shutdown, 當(dāng)執(zhí)行完畢后向Power manager發(fā)送設(shè)備電源模式切換完成的event；同時(shí)會觸發(fā)對設(shè)備及系統(tǒng)電源模式切換關(guān)心的app即Power sensitive apps發(fā)送event；

對設(shè)備及系統(tǒng)電源模式切換關(guān)心的Power sensitive apps執(zhí)行相應(yīng)的處理。

2. QNX客戶端API庫

驅(qū)動(dòng)程序API：

客戶端庫提供了允許驅(qū)動(dòng)程序和電源管理服務(wù)之間雙向通信的基本服務(wù)：

驅(qū)動(dòng)程序初始化時(shí)需要向電源管理服務(wù)進(jìn)行注冊，這樣系統(tǒng)電源狀態(tài)更改才去通知這個(gè)驅(qū)動(dòng)

電源管理服務(wù)根據(jù)系統(tǒng)電源模式策略通知驅(qū)動(dòng)程序更改電源模式。

驅(qū)動(dòng)程序向電源管理服務(wù)報(bào)告其電源模式狀態(tài)。

驅(qū)動(dòng)程序可以選擇向電源管理服務(wù)請求自主電源模式更改。

功耗敏感程序API：

功耗敏感程序要想電源管理服務(wù)注冊感興趣的系統(tǒng)電源狀態(tài)或者某個(gè)設(shè)備的電源狀態(tài)

接收電源模式更改的通知

查詢特定服務(wù)或驅(qū)動(dòng)程序的電源模式

請求更改特定服務(wù)或驅(qū)動(dòng)程序的電源模式。

系統(tǒng)監(jiān)控應(yīng)用程序的API：

系統(tǒng)監(jiān)控程序需要給電源管理服務(wù)上報(bào)各種參數(shù)，例如電量、溫度等。

管理與電源管理器對象關(guān)聯(lián)的屬性。這些屬性可以包括由產(chǎn)品特定系統(tǒng)電源管理策略處理的任意數(shù)據(jù)，以確定最合適的電源模式

根據(jù)自己的評估標(biāo)準(zhǔn)請求特定服務(wù)或驅(qū)動(dòng)程序的電源模式更改。

例如查詢設(shè)備自己的電源模式：

pm_power_attr_t attr;

if (pm_getattr(hdl, &attr) == -1) {
   error...
}

printf("Current mode is %d
", attr.cur_mode);
if (attr.new_mode != attr.cur_mode)
   printf("Device is changing modes to %d
", attr.new_mode);
if (attr.nxt_mode != attr.new_mode)
   printf("Pending mode change to %d
", attr.nxt_mode);

改變電源模式：

int status;

// attempt to change mode, subject to the power manager policy
if (pm_setmode(hdl, mode, 0) == -1) {
   if (errno == EACCES) {
      // force the power mode to change
      pm_setmode(hdl, mode, PM_MODE_FORCE);
   } else {
      error...
   }
}

3. QNX代碼分析

這里以關(guān)機(jī)為例shutdown：關(guān)機(jī)或重啟之前會正確地中止進(jìn)程及服務(wù)，代碼路徑：utilssshutdownmain.c

先對命令參數(shù)進(jìn)行解析：-b是重啟 -S r是重啟

調(diào)用庫函數(shù)shutdown_system（）進(jìn)行重啟

庫函數(shù)shutdown_system（），代碼路徑：libshutdownshutdown.c

提高進(jìn)程優(yōu)先級

根據(jù)"/proc"目錄下進(jìn)程，構(gòu)建所有正在運(yùn)行的進(jìn)程的列表，申請內(nèi)存空間pidvec存放

按進(jìn)程的class值排序，然后順序發(fā)送SIGTERM來關(guān)閉進(jìn)程，kill(pip->pid, SIGTERM)

等待一段時(shí)間直到進(jìn)程被殺死為止，如果時(shí)間到了還沒殺死且class <= CLASS_APP則發(fā)送SIGKILL信號

此時(shí)，所有非顯示過程都已關(guān)閉。調(diào)用shutdown_done（）函數(shù)做顯示更新

如果是重啟，則調(diào)用sysmgr_reboot

釋放pidvec內(nèi)存空間

sysmgr_reboot（）函數(shù)，代碼中位置：libcservicessysmgr_reboot.c

int sysmgr_reboot(void) {
    sys_cmd_t                   msg;

    msg.i.type = _SYS_CMD;
    msg.i.cmd = _SYS_CMD_REBOOT;
    
    return MsgSendnc(SYSMGR_COID, &msg.i, sizeof msg.i, 0, 0);
}

servicessystemkerminiproc_start.c中do_miniproc（）函數(shù)進(jìn)行處理

case _SYS_CMD_REBOOT:
    RebootSystem(0);
    break;

之后執(zhí)行servicessystemkerkerext_reboot.c中reboot（）函數(shù)

static void
reboot(void *abnormal) {
    lock_kernel();
    cpu_reboot();
    calloutptr->reboot(_syspage_ptr, (int)abnormal);
}

屏蔽內(nèi)核中斷

執(zhí)行cpu重啟

回調(diào)calloutptr->reboot函數(shù)

4. Fuchsia中的電源管理

初始化：

src/power/power-manager/src/main.rs中找到main函數(shù)

async fn main() -> Result<(), Error> {
    // Setup logging
    fuchsia_syslog::init()?;
    log::info!("started");

    // Setup tracing
    fuchsia_trace_provider::trace_provider_create_with_fdio();

    // Set up the PowerManager
    let mut pm = PowerManager::new();

    // This future should never complete
    let result = pm.run().await;
    log::error!("Unexpected exit with result: {:?}", result);
    result
}

run函數(shù)在模塊PowerManager中

/// Perform the node initialization and begin running the PowerManager.
pub async fn run(&mut self) -> Result<(), Error> {
    // Create a new ServiceFs to handle incoming service requests for the various services that the PowerManager hosts.
    let mut fs = ServiceFs::new_local();

    // Allow our services to be discovered.
    fs.take_and_serve_directory_handle()?;

    // Required call to serve the inspect tree
    let inspector = component::inspector();
    inspect_runtime::serve(inspector, &mut fs)?;

    // Create the nodes according to the config file
    let node_futures = FuturesUnordered::new();
    self.create_nodes_from_config(&mut fs, &node_futures).await?;

    // Run the ServiceFs (handles incoming request streams) and node futures. This future never completes.
    futures::select(fs, node_futures).collect::<()>().await;

    Ok(())
}

SystemPowerModeHandler

這里有很多種type,例如電源模式"SystemPowerModeHandler"，主要執(zhí)行了new_from_json和build這兩個(gè)函數(shù)

SystemShutdownHandler

每個(gè)類型的Handler調(diào)用new_from_json函數(shù)將json文件中的配置賦給handler結(jié)構(gòu)體，然后調(diào)用build方法，初始化handler實(shí)例，啟動(dòng)服務(wù)線程。

這里不詳細(xì)說明了，大家可以自己去看代碼。

5. Minix中的電源管理

Minix也是一個(gè)微內(nèi)核，介紹見之前的文章：MINIX3入門-簡介及代碼編譯運(yùn)行，有興趣自己看看代碼。

6. Harmony OS中的電源管理

Harmony OS也是一個(gè)微內(nèi)核

電源管理服務(wù)組件提供如下功能：

重啟系統(tǒng)。

管理休眠運(yùn)行鎖。

系統(tǒng)電源狀態(tài)查詢。

后記：

微內(nèi)核中電源管理和各種驅(qū)動(dòng)都被實(shí)現(xiàn)為APP，各種應(yīng)用APP一般之前是根據(jù)Linux開發(fā)的，也不可能在微內(nèi)核上重新開發(fā)一遍，那這些應(yīng)用APP是符合UNIX編程函數(shù)規(guī)范的，也就是符合POSIX規(guī)范，一個(gè)最大的特點(diǎn)就是其規(guī)定了一系列的系統(tǒng)調(diào)用支持這些應(yīng)用APP。那么在微內(nèi)核中需要再加一個(gè)殼子來提供這些POSIX接口，從而擴(kuò)展微內(nèi)核支持的系統(tǒng)調(diào)用，不在微內(nèi)核中的電源管理和驅(qū)動(dòng)等需要跟這個(gè)殼子交互來對應(yīng)用提供服務(wù)，或者直接跟電源管理和驅(qū)動(dòng)的server APP交互（這時(shí)需要重寫應(yīng)用APP的代碼接口）。

審核編輯：劉清