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

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

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

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

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

Client和Server之間通過IPC通信，約定好通信的報文

1. QNX電源管理框架

電源管理服務可以：

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

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

電源管理架構的主要組件是：

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

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

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

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

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

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

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

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

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

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

Off：指示實體已斷電且不可操作。

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

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

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

總結如下：

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

各個device driver or service啟動過程中會向power manager server注冊

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

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

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

2. QNX客戶端API庫

驅(qū)動程序API：

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

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

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

驅(qū)動程序向電源管理服務報告其電源模式狀態(tài)。

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

功耗敏感程序API：

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

接收電源模式更改的通知

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

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

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

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

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

根據(jù)自己的評估標準請求特定服務或驅(qū)動程序的電源模式更改。

例如查詢設備自己的電源模式：

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代碼分析

這里以關機為例shutdown：關機或重啟之前會正確地中止進程及服務，代碼路徑：utilssshutdownmain.c

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

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

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

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

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

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

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

此時，所有非顯示過程都已關閉。調(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ù)進行處理

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這兩個函數(shù)

SystemShutdownHandler

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

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

5. Minix中的電源管理

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

6. Harmony OS中的電源管理

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

電源管理服務組件提供如下功能：

重啟系統(tǒng)。

管理休眠運行鎖。

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

后記：

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

審核編輯：劉清