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

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

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

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

電源管理服務的對象Client：電源敏感APP、驅動APP、電源監控APP

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

1. QNX電源管理框架

電源管理服務可以：

可以控制各個設備包括CPU的電源狀態

一組電源管理服務，用于實現電源管理策略，可以管理應用APP即設備硬件驅動APP、電源敏感APP、電源監控APP

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

實施系統電源管理策略的電源管理服務

與電源管理器交互以根據系統策略調整功率級別的設備驅動程序

電源監控應用程序——可以提供電源管理策略使用的輸入事件或數據

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

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

電源管理狀態：

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

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

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

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

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

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

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

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

總結如下：

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

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

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

Audio、Video設備驅動內部執行電源模式切換：Active->Shutdown, 當執行完畢后向Power manager發送設備電源模式切換完成的event；同時會觸發對設備及系統電源模式切換關心的app即Power sensitive apps發送event；

對設備及系統電源模式切換關心的Power sensitive apps執行相應的處理。

2. QNX客戶端API庫

驅動程序API：

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

驅動程序初始化時需要向電源管理服務進行注冊，這樣系統電源狀態更改才去通知這個驅動

電源管理服務根據系統電源模式策略通知驅動程序更改電源模式。

驅動程序向電源管理服務報告其電源模式狀態。

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

功耗敏感程序API：

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

接收電源模式更改的通知

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

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

系統監控應用程序的API：

系統監控程序需要給電源管理服務上報各種參數，例如電量、溫度等。

管理與電源管理器對象關聯的屬性。這些屬性可以包括由產品特定系統電源管理策略處理的任意數據，以確定最合適的電源模式

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

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

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

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

調用庫函數shutdown_system（）進行重啟

庫函數shutdown_system（），代碼路徑：libshutdownshutdown.c

提高進程優先級

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

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

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

此時，所有非顯示過程都已關閉。調用shutdown_done（）函數做顯示更新

如果是重啟，則調用sysmgr_reboot

釋放pidvec內存空間

sysmgr_reboot（）函數，代碼中位置：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（）函數進行處理

case _SYS_CMD_REBOOT:
    RebootSystem(0);
    break;

之后執行servicessystemkerkerext_reboot.c中reboot（）函數

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

屏蔽內核中斷

執行cpu重啟

回調calloutptr->reboot函數

4. Fuchsia中的電源管理

初始化：

src/power/power-manager/src/main.rs中找到main函數

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函數在模塊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"，主要執行了new_from_json和build這兩個函數

SystemShutdownHandler

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

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

5. Minix中的電源管理

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

6. Harmony OS中的電源管理

Harmony OS也是一個微內核

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

重啟系統。

管理休眠運行鎖。

系統電源狀態查詢。

后記：

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

審核編輯：劉清