本主題提供使用 ACPI 服務平臺擴充功能外掛程式 （PEP） 的相關信息。
PEPs 提供動態執行時期的 ACPI 方法。 靜態數據表（FADT、MADT、DBG2 等）必須在 ACPI 韌體中實作，以及 DSDT/SSDT 裝置階層。
PEP 用於非 SoC 電源管理方法。 因為它們是可安裝的二進位檔，因此可以即時更新，而不是需要韌體快閃的ACPI韌體。 這表示，您可以藉由在 Windows Update 上張貼更新的驅動程式，來改善已出貨平臺的電源管理程式碼。 電源管理是PEPs的原始意圖，但它們可以用來提供或覆蓋任何任意的ACPI運行階段方法。
PEP 在 ACPI 命名空間階層的建構中沒有作用，因為必須在韌體 DSDT 中提供命名空間階層。 當 ACPI 驅動程式在運行時間評估方法時，它會檢查有關裝置的 PEP 實作方法，如果有的話，它會執行 PEP 並忽略韌體的版本。 不過，裝置本身必須在韌體中定義。
使用 PEP 提供電源管理比針對 ACPI 韌體撰寫的程式代碼更容易偵錯，因為工具可用。 大部分的人對 ACPI 韌體的除錯工具都不熟悉，而且工具選項有限。 相反地，PEP 會開發為 Windows 驅動程式，讓開發人員可以使用他們最熟悉的開發和偵錯工具。
當使用 PEP 取代 ACPI 服務時，不需要採取任何特殊動作或操作來取得服務的角色。 在 PEP 中實作方法時，Windows 會自動使用它。 如果提供相同裝置上相同方法的韌體版本，則會予以忽略。
PE 會非常早載入，以便其服務可供設備驅動器使用。 此外，透過 Windows 的抽象層設計成對設備驅動器而言是透明的。 驅動程式應該能夠與其 ACPI 方法互動，就像 PEP 未使用一樣。
針對裝置電源管理 （DPM） 和 ACPI 服務使用 PEP 時，建議使用個別的 PEP 句柄，但這隻是偏好的問題。 共用句柄 DPM 和 ACPI 狀態時，可以輕鬆地追蹤裝置的句柄，因為句柄相同。 不過，處理生命周期管理有點複雜。 PEP 必須提供句柄的參考計數，以確保只有在該句柄上收到 PEP_DPM_UNREGISTER_DEVICE 和 PEP_NOTIFY_ACPI_UNREGISTER_DEVICE 之後，才會刪除它。 使用不同的控制代碼時，將會個別追蹤 DPM 和 ACPI 狀態，但控制代碼的生命週期管理更簡單。 在此情況下，當對應的取消註冊通知傳送時，可以銷毀句柄。
為了簡化使用 ACPI 資源的程式，電源管理架構 （PoFx） 會提供PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES協助程式例程，將 ACPI 資源轉換為 BIOS 資源。
PEP 負責排程那些無法同步執行的工作，以回應來自 PoFx 的 ACPI 通知，但所使用的方法由 PEP 開發人員決定。 一般而言，PEP 會將工作排入某個內部佇列，如果需要則啟動工作執行緒。 此外，工作也可能需要等候某些外部事件（例如裝置中斷），並會在該事件的上下文中處理。 工作完成後，PEP 可以叫用 PEP_KERNEL_INFORMATION_STRUCT_V3->RequestWorker() 來要求 PoFx 查詢工作。 回應中，PoFx 會針對實作 DPM 通知處理程式的PE傳送 PEP_DPM_WORK通知 （AcceptDeviceNotification）或實作僅限 ACPI 通知處理程式的PE的 PEP_NOTIFY_ACPI_WORK通知 （AcceptAcpiNotification）。
相關主題
ACPI 系統描述數據表
裝置電源管理 （DPM） 通知
PEP_DPM_UNREGISTER_DEVICEPEP_NOTIFY_ACPI_UNREGISTER_DEVICEPEP_KERNEL_INFORMATION_STRUCT_V3
RequestWorker
AcceptDeviceNotification
ACPI 通知