Almost all modern computer system hardware allows its power usage to be managed and its temperature to be monitored and kept at the appropriate level. This allows users to achieve the best performance from a system for a given level of power usage. This is especially important for battery-driven mobile platforms where unnecessary use of power reduces battery life and thus reduces the amount of work that can be done before a recharge is necessary. It is also useful in desktop environments where devices such as computer monitors and disk drives can be powered down during idle times to reduce energy consumption.
Unfortunately, in the typical PC most of the software that configures and manages the power and thermal environment within the computer is locked up within the BIOS. In addition, unless a power management device is attached to a PnP bus (e.g. PCI), the operating system has no easy way to detect, configure, or manage it. For example, mechanisms such as ISA PnP are usually used to enumerate add-on ISA cards rather than for on-board devices. Systems like PnP BIOS can be used to enumerate on-board devices, but it is hard to extend in a generic way. Also, PnP BIOS is written in 16-bit code, so the operating system must use 16-bit emulation in order to call PnP BIOS functions.
Prior to the introduction of the Advanced Configuration and Power Management Interface (ACPI), the Advanced Power Management (APM) BIOS was commonly used for power management. In APM, the bulk of the power management control and logic resides within the APM BIOS code itself. APM-aware operating systems communicate with the APM BIOS through a fixed BIOS API which provides basic access to BIOS functions. APM-aware operating systems must periodically poll APM for APM-related events that must be processed. The APM BIOS may also make use of special system management interrupts which are invisible to the operating system itself. APM provides four states: run, suspend, sleep and soft-off.
APM has three main limitations. First, without special vendor programs, many APM features are only available through vendor-specific BIOS menus before the operating system is loaded. For example, the amount of console idle time required before powering down the video display is usually configured this way. Also, with APM, the number of power management configurations are fixed by the BIOS vendor. For example, the APM BIOS may always slow the CPU clock or power down other devices (e.g. networking card) when powering down the monitor. Since this is under control of the BIOS, there is no way to change the policy without changing the BIOS.
Second, APM is BIOS-level code that operates outside of the scope of the operating system. This make developing and debugging APM code a challenge. It also means that users can only fix bugs in their APM BIOS by flashing a new one into ROM. Flashing a new BIOS is a dangerous operation because if the BIOS fails, the system may well become useless.
Third, as APM is vendor-specific, efforts to develop and maintain the complex APM BIOS code are duplicated across the vendors that use it. This is wasteful.
ACPI addresses the limitations of APM and other configuration mechanisms by unifying all device management within the operating system kernel rather than having BIOS code make most of the decisions. Thus, ACPI is said to allow ``operating system directed'' power and thermal management that is more flexible than other mechanisms. The cost of this flexibility is the extra complexity required in the kernel to support ACPI. In this paper we describe ACPI, how it is implemented in FreeBSD, and the lessons we learned from working with ACPI. In Section 2 we describe the general architecture of ACPI. Section 3 explains the architecture of the FreeBSD ACPI implementation and its impact on the rest of the kernel. Section 4 contains related work, and Section 5 has our conclusions and future work.