網路上沒看到繁體的翻譯
簡體版的有找到但好像沒校稿，看起來頗難過
乾脆自己翻
本篇翻譯使用DeepL先做初次翻譯，再自己人工校稿
後面如果有別的章節的翻譯，基本上也會採用同樣的模式
本章節為第0章的overview部分
對ACPI完全沒概念的話
官方在本章寫了一個實際應用的範例
看了會稍稍稍稍微有點知道ACPI在幹嘛～
下面是採用先寫出英文，後面接著中文翻譯的方式
圖片就沒翻譯了，作圖很費時，呵呵，頂多在底下稍微加註，湊活著看
=====
Overview 概述
This chapter provides a high-level overview of the Advanced Configuration and Power Interface (ACPI). To make it easier to understand ACPI, this section focuses on broad and general statements about ACPI and does not discuss every possible exception or detail about ACPI. The rest of the ACPI specification provides much greater detail about the inner workings of ACPI than is discussed here, and is recommended reading for developers using ACPI.
本章提供了高級配置和電源接口（ACPI）的高層次概述。 為了使人們更容易理解ACPI，本節重點介紹了關於ACPI的寬泛和一般的聲明，並沒有討論ACPI的每一個可能的例外或細節。 ACPI規範的其他部分提供了比這裡討論的更詳細的ACPI內部工作原理，建議使用ACPI的開發人員閲讀。
History of ACPI ACPI的歷史
ACPI was developed through collaboration between Intel, Microsoft*, Toshiba*, HP*, and Phoenix* in the mid-1990s. Before the development of ACPI, operating systems (OS) primarily used BIOS (Basic Input/Output System) interfaces for power management and device discovery and configuration. This power management approach used the OS’s ability to call the system BIOS natively for power management. The BIOS was also used to discover system devices and load drivers based on probing input/output (I/O) and attempting to match the correct driver to the correct device (plug and play). The location of devices could also be hard coded within the BIOS because the platform itself was non-enumerable.
ACPI是英特爾、微軟*、東芝*、惠普*和鳳凰*在90年代中期合作開發的。 在ACPI開發之前，操作系統(OS)主要使用BIOS(基本輸入/輸出系統)接口進行電源管理和設備發現與配置。 這種電源管理方式利用操作系統原生調用系統BIOS進行電源管理的能力。 BIOS還被用來發現系統設備，並根據探測輸入/輸出（I/O）加載驅動程序，並試圖將正確的驅動程序與正確的設備相匹配（即插即用）。 設備的位置也可以在BIOS內進行硬編碼（hard coded），因為平台本身是不可枚舉的（non-enumerable）。
These solutions were problematic in three key ways. First, the behavior of OS applications could be negatively affected by the BIOS-configured power management settings, causing systems to go to sleep during presentations or other inconvenient times. Second, the power management interface was proprietary on each system. This required developers to learn how to configure power management for each individual system. Finally, the default settings for various devices could also conflict with each other, causing devices to crash, behave erratically, or become undiscoverable.
這些解決方案在三個關鍵方面存在問題。 首先，操作系統應用程序的行為可能會受到BIOS配置的電源管理設置的負面影響，導致系統在作演示（presentations）或其他不方便的時候進入睡眠狀態。 其次，每個系統的電源管理接口都是專有的。 這就要求開發人員學習如何為每個系統配置電源管理。 最後，各種設備的預設設置也可能相互衝突，導致設備崩潰、行為不穩定或無法被發現（undiscoverable）。
ACPI was developed to solve these problems and others.
ACPI的開發就是為了解決這些問題和其他問題。
What is ACPI? 什麼是ACPI？
ACPI can first be understood as an architecture-independent power management and configuration framework that forms a subsystem within the host OS. This framework establishes a hardware register set to define power states (sleep, hibernate, wake, etc). The hardware register set can accommodate operations on dedicated hardware and general purpose hardware.
ACPI首先可以理解為一個獨立於架構的（architecture-independent）電源管理和配置框架，在主機操作系統中形成一個子系統。 這個框架建立了一個硬體暫存器集來定義電源狀態（睡眠、休眠、喚醒等）。 硬體暫存器集可以適應對專用硬體和通用硬體的操作。
The primary intention of the standard ACPI framework and the hardware register set is to enable power management and system configuration without directly calling firmware natively from the OS. ACPI serves as an interface layer between the system firmware (BIOS) and the OS, as shown in Figure 0-1 and Figure 0-2, with certain restrictions and rules.
標準ACPI框架和硬體暫存器集的主要目的是實現電源管理和系統配置，而無需直接從操作系統中調用韌體。如圖0-1和圖0-2所示，ACPI作為系統韌體（BIOS）和操作系統之間的接口層，有一定的限制和規則。
（ACPI子系統是系統韌體和操作系統之間的接口層。箭頭表示資料流）
Fundamentally, ACPI defines two types of data structures that are shared between the system firmware and the OS: data tables and definition blocks. These data structures are the primary communication mechanism between the firmware and the OS. Data tables store raw data and are consumed by device drivers. Definition blocks consist of byte code that is executable by an interpreter.
從根本上講，ACPI定義了系統韌體和操作系統之間共享的兩類數據結構：數據表和定義塊（data tables and definition blocks）。 這些數據結構是韌體和操作系統之間的主要通信機制。 數據表存儲原始數據（raw data），由設備驅動程序消耗（consume? not so sure.）。 定義塊由可由解釋器（interpreter）執行的位元組代碼（byte code）組成。
This definition block byte code is compiled from the ACPI Source Language (ASL) code. ASL is the language used to define ACPI objects and to write control methods. An ASL compiler translates ASL into ACPI Machine Language (AML) byte code. AML is the language processed by the AML interpreter, as shown in Figure 0-3.
這個定義塊位元組代碼 是由ACPI源語言（ASL）代碼 編譯而成。 ASL是用來定義ACPI對象和編寫控制方法的語言。 ASL編譯器將ASL翻譯成ACPI機器語言（AML）位元組代碼。 AML是由AML解釋器處理的語言，如圖0-3所示。
The AML interpreter executes byte code and evaluates objects in the definition blocks to allow the byte code to perform loop constructs, conditional evaluations, access defined address spaces, and perform other operations that applications require. The AML interpreter has read/write access to defined address spaces, including system memory, I/O, PCI configuration, and more. It accesses these address spaces by defining entry points called objects. Objects can either have a directly defined value or else must be evaluated and interpreted by the AML interpreter.
AML解釋器執行位元組代碼，並對定義塊中的對象（或物件？）進行評估，使位元組代碼（byte code）能夠執行循環結構、條件評估、訪問定義的地址空間，並執行應用所需的其他操作。 AML解釋器可以對定義的地址空間進行讀/寫訪問，包括系統內存、I/O、PCI配置等。 它通過定義稱為對象的入口點（entry points）來訪問這些地址空間。 對象可以有一個直接定義的值，否則必須由AML解釋器進行評估和解釋。
This collection of enumerable objects is an OS construct called the ACPI namespace. The namespace is a hierarchical representation of the ACPI devices on a system. The system bus is the root of enumeration for these ACPI devices. Devices that are enumerable on other buses, like PCI or USB devices, are usually not enumerated in the namespace. Instead, their own buses enumerate the devices and load their drivers. However, all enumerable buses have an encoding technique that allows ACPI to encode the bus-specific addresses of the devices so they can be found in ACPI, even though ACPI usually does not load drivers for these devices.
這個可枚舉對象的集合是一個稱為ACPI命名空間的操作系統結構（OS construct）。 命名空間是系統上ACPI設備的層次表示（hierarchical representation）。 系統匯流排是這些ACPI設備的枚舉根（root of enumeration）。 在其他匯流排上可枚舉的設備，如PCI或USB設備，通常不在命名空間中枚舉。 相反，它們自己的匯流排會枚舉設備並加載它們的驅動程序。 然而，所有可枚舉的匯流排都有一種編碼技術，允許ACPI對設備的匯流排特定地址進行編碼，這樣就可以在ACPI中找到它們，即使ACPI通常不加載這些設備的驅動程序。
Generally, devices that have a _HID object (hardware identification object) are enumerated and have their drivers loaded by ACPI. Devices that have an _ADR object (physical address object) are usually not enumerated by ACPI and generally do not have their drivers loaded by ACPI. _ADR devices usually can perform all necessary functions without involving ACPI, but in cases where the device driver cannot perform a function, or if the driver needs to communicate to system firmware, ACPI can evaluate objects to perform the needed function.
一般來說，具有_HID對象（硬體識別對象）的設備會被列舉出來，並由ACPI加載其驅動程序。 具有_ADR對象（物理地址對象）的設備通常不被ACPI枚舉，並且通常不由ACPI加載其驅動程序。 _ADR設備通常可以在不涉及ACPI的情況下執行所有必要的功能，但在設備驅動程序不能執行某項功能的情況下，或者驅動程序需要與系統韌體通信時，ACPI可以評估對象來執行所需的功能。
As an example of this, PCI does not support native hotplug. However, PCI can use ACPI to evaluate objects and define methods that allow ACPI to fill in the functions necessary to perform hotplug on PCI.
舉個例子，PCI不支持本地熱插拔（native hotplug）。 然而，PCI可以使用ACPI來評估對象並定義方法，使ACPI能夠填補在PCI上執行熱插拔所需的功能。
An additional aspect of ACPI is a runtime model that handles any ACPI interrupt events that occur during system operation. ACPI continues to evaluate objects as necessary to handle these events.
ACPI的另一個方面是一個運行時模型，它可以處理系統運行期間發生的任何ACPI中斷事件。 ACPI在必要時繼續評估對象以處理這些事件。
This interrupt-based runtime model is discussed in greater detail in the Runtime model section below.
這種基於中斷的運行時模型，將在下面的運行時模型部分詳細討論。
ACPI Initialization ACPI初始化
The best way to understand how ACPI works is chronologically. The moment the user powers up the system, the system firmware completes its setup, initialization, and self tests.
理解ACPI工作原理的最好方法是按時間順序進行。 在用戶開機的那一刻，系統韌體就完成了設置、初始化和自我測試。
The system firmware then uses information obtained during firmware initialization to update the ACPI tables as necessary with various platform configurations and power interface data, before passing control to the bootstrap loader. The extended root system description table (XSDT) is the first table used by the ACPI subsystem and contains the addresses of most of the other ACPI tables on the system. The XSDT points to the fixed ACPI description table (FADT) as well as other major tables that the OS processes during initialization. After the OS initializes, the FADT directs the ACPI subsystem to the differentiated system description table (DSDT), which is the beginning of the namespace because it is the first table that contains a definition block.
然後，系統韌體會利用韌體初始化過程中獲得的信息，根據需要更新ACPI表中的各種平台配置和電源接口數據，然後再將控制權傳遞給bootstrap loader。 擴展的根系統描述表(XSDT)是ACPI子系統使用的第一個表，它包含了系統上大多數其他ACPI表的地址。 XSDT指向固定的ACPI描述表（FADT）以及操作系統在初始化過程中處理的其他主要表。 在操作系統初始化後，FADT將ACPI子系統引導到區分系統描述表（DSDT），其中，DSDT是命名空間的開始，因為它是第一個包含定義塊的表。
The ACPI subsystem then processes the DSDT and begins building the namespace from the ACPI definition blocks. The XSDT also points to the secondary system description tables (SSDTs) and adds them to the namespace. The ACPI data tables give the OS raw data about the system hardware.
然後，ACPI子系統處理DSDT，並開始從ACPI定義塊構建命名空間。 XSDT還指向二級系統描述表（secondary system description tables，SSDT），並將它們添加到命名空間中。 ACPI數據表給操作系統提供了系統硬體的原始數據。
After the OS has built the namespace from the ACPI tables, it begins traversing the namespace and loading device drivers for all the _HID devices it encounters in the namespace.
操作系統從ACPI表中建立起命名空間後，開始遍歷（traversing）命名空間，並為命名空間中遇到的所有_HID設備加載設備驅動程序。
Runtime Model 運行時模型
After the system is up and running, ACPI works with the OS to handle any ACPI events that occur via an interrupt. This interrupt invokes ACPI events in one of two general ways: fixed events and general purpose events (GPEs).
在系統啟動並運行後，ACPI與操作系統合作，通過中斷來處理任何ACPI事件。 這個中斷一般以兩種方式之一調用（invoke）ACPI事件：固定事件（fixed events）和通用事件（general purpose events，GPE）。
Fixed events are ACPI events that have a predefined meaning in the ACPI specification. These fixed events include actions like pressing the power button or ACPI timer overflows. These events are handled directly by the OS handlers.
固定事件是ACPI規範中具有預定義的ACPI事件。 這些固定事件包括按下電源按鈕或ACPI定時器溢出等動作。 這些事件由操作系統處理程序（OS handlers）直接處理。
GPEs are ACPI events that are not predefined by the ACPI specification. These events are usually handled by evaluating control methods, which are objects in the namespace and can access system hardware. When the ACPI subsystem evaluates the control method with the AML interpreter, the GPE object handles the events according to the OS’s implementation. Typically this might involve issuing a notification to a device to invoke the device driver to perform a function.
GPEs是ACPI規範中沒有預定義的ACPI事件。 這些事件通常通過評估控制方法來處理，控制方法是命名空間中的對象，可以訪問系統硬體。 當ACPI子系統用AML解釋器評估控制方法時，GPE對象會根據操作系統的實現（OS’s implementation）來處理這些事件。 通常，這可能涉及向設備發出通知，以調用設備驅動程序來執行功能。
We discuss a generic example of this runtime model in the next section.
我們將在下一節討論這種運行時模型的一個通用示例。
Thermal Event Example 熱事件示例
ACPI includes a thermal model to allow systems to control the system temperature either actively (by performing actions like turning a fan on) or passively by reducing the amount of power the system uses (by performing actions like throttling the processor). We can use an example of a generic thermal event shown in Figure 5 to demonstrate how the ACPI runtime model works.
ACPI包含了一個熱模型（thermal model），以允許系統主動控制系統溫度（通過執行諸如打開風扇等動作），或被動地減少系統的功耗（通過執行諸如節流處理器等動作）。 我們可以用圖5所示的一個通用熱事件的例子來演示ACPI運行時模型的工作原理。
（PS1：handler：處理程式，trip point：跳脫點）
（PS2：thermal zone直譯為熱區，參國家教育研究院正式翻譯為『溫度帶』，後採溫度帶之翻譯）
The ACPI thermal zone includes control methods to read the current system temperature and trip points.
ACPI溫度帶包括讀取當前系統溫度和跳脫點（trip points）的控制方法。
When the OS initially finds a thermal zone in the namespace, it loads the thermal zone driver, which evaluates the thermal zone to obtain the current temperature and trip points.
當操作系統最初在命名空間中找到一個溫度帶（thermal zone）時，它將加載熱區驅動程序，該驅動程序評估溫度帶以獲得當前溫度和跳脫點。
When a system component heats up enough to trigger a trip point, a thermal zone GPE occurs.
當系統組件加熱到足以觸發跳脫點時，就會發生溫度帶GPE。
The GPE causes an interrupt to occur. When the ACPI subsystem receives the interrupt, it first checks whether any fixed events have occurred. In this example, the thermal zone event is a GPE, so no fixed event has occurred.
GPE會導致一個中斷發生。 當ACPI子系統接收到中斷時，它首先檢查是否有任何固定事件發生。 在本例中，溫度帶事件是一個GPE，所以沒有固定事件發生。
The ACPI subsystem then searches the namespace for the control method that matches the GPE number of the interrupt. Upon finding it, the ACPI subsystem evaluates the control method, which might then access hardware and/or notify the thermal zone handler.
然後，ACPI子系統在命名空間中搜索與中斷的GPE號相匹配的控制方法。 找到它後，ACPI子系統會評估控制方法，然後它可能會訪問硬體和/或通知溫度帶處理程序。
The operating system’s thermal zone handler then takes whatever actions are necessary to handle the event, including possibly accessing hardware.
然後，操作系統的溫度帶處理程序會採取任何必要的行動來處理該事件，包括可能訪問硬體。
ACPI is a very robust interface implementation. The thermal zone trip point could notify the system to turn on a fan, reduce a device’s performance, read the temperature, shut down the system, or any combination of these and other actions depending on the need.
ACPI是一個非常強大的接口實現。 溫度帶跳脫點可以通知系統打開風扇、降低設備的性能、讀取溫度、關閉系統，或者根據需要將這些動作和其他動作任意組合。
This runtime model is used throughout the system to manage all of the ACPI events that occur during system operation.
這個運行時模型在整個系統中用於管理系統運行中發生的所有ACPI事件。
Summary 總結
ACPI can best be described as a framework of concepts and interfaces that are implemented to form a subsystem within the host OS. The ACPI tables, handlers, interpreter, namespace, events, and interrupt model together form this implementation of ACPI, creating the ACPI subsystem within the host OS. In this sense, ACPI is the interface between the system hardware/firmware and the OS and OS applications for configuration and power management. This gives various OS a standardized way to support power management and configuration via the ACPI namespace.
ACPI可以最好地描述為一個概念和接口的框架（framework of concepts and interfaces），這些概念和接口的實現 在 主機操作系統內形成一個子系統。 ACPI表、處理程序、解釋器、命名空間、事件和中斷模型共同構成了ACPI的這種實現方式，在主機操作系統內部形成了ACPI子系統。 從這個意義上說，ACPI是系統硬體/韌體與操作系統和操作系統應用程序之間的接口，用於配置和電源管理。 這就給各種OS提供了一種標準化的方式，通過ACPI命名空間來支持電源管理和配置。
The ACPI namespace is the enumerable, hierarchical representation of all ACPI devices on the system and is used to both find and load drivers for ACPI devices on the system. The namespace can be dynamic by evaluating objects and sending interrupts in real time, all without the need for the OS to call native system firmware code. This enables device manufacturers to code their own instructions and events into devices. It also reduces incompatibility and instability by implementing a standardized power management interface.
ACPI命名空間是系統上所有ACPI設備的可枚舉的、層次化的表示，用於查找和加載系統上ACPI設備的驅動程序。 命名空間可以通過評估對象和實時發送中斷來實現動態，所有這些都不需要操作系統調用本地系統韌體代碼。 這使得設備製造商可以將自己的指令和事件編碼到設備中。 它還可以通過實現標準化的電源管理接口來減少不兼容性和不穩定性。
留言列表
