hiten@unixdaemons.com
FreeBSD is becoming more popular for mobile computing devices. With this comes the question of how an operating system will effectively utilize system resources, and stay within system limits. In this article, I will explain what ACPI is, and how to utilize it on FreeBSD. References will be provided for further reading, at the end of the article.
I would like to thank the following entities for making ACPI support possible in FreeBSD: Michael Smith, Takanori Watanabe, Mitsuru IWASAKI, Munehiro Matsuda, the ACPI-jp mailing list.
It is very important to utilize hardware resources in an efficient manner. Before ACPI was introduced, it was very difficult and unflexible for operating systems to manage the power usage and thermal properties of a system. The hardware was either controlled by some sort of BIOS embedded interface, e.g. Plug and Play BIOS (PNPBIOS), Advanced Power Management (APM) and so on. Power and Resource Management is one of the key components of a modern operating system. For example, you would want an OS to monitor system limits (and possibly take an action), in case your its temperature increased unexpectedly.
The Advanced Configuration and Power Interface (ACPI) is a standard written by an alliance of vendors, to have a standard interface for hardware resources and power management (hence the name). It is a key element in Operating System-directed configuration and Power Management, i.e. it provides more control and flexibility to the operating system (OS). Modern systems ``stretched'' the limits of the current Plug and Play interfaces (such as APM, which is used in FreeBSD 4.X), prior to the introduction of ACPI. ACPI is the direct successor to APM (Advanced Power Management).
The list below outline's goals of the ACPI standard:
Improve power management functionality and robustness
Allow power management policies to be implemented in the OS, which, allows inexpensive hardware to support very elaborate power management policies
Unifying power management algorithms, to reduce conflicts between the firmware and OS, thus enhancing reliability
Let the OS evolve independently of the hardware, which allows ``ACPI enabled'' machines to enjoy the benefits of its improvements and innovations
Basically, it is an evolution from a ``collection'' of hardware interfaces, such as Advanced Power Management (APM), PNPBIOS, Multi-Processor Specification etc, into a one well defined, and robust common hardware interface. The ACPI standard provides use with many useful features apart from power management, such as device events, thermal management, cpu throttling, etc.
By now, you must be wondering, why have one more standard to do the job which APM, MPS, and the other plethora of specifications does? Well, what ACPI does, is merge all these standards into one unified standard, and by handing over all power management responsibilities to the OS system. It is known as OS-directed configuration and Power Management (OSPM) in ACPI terminology. This gives us more flexibility and lets us adapt to upcoming technologies easily. The next section discusses how the OS and the user benefit from ACPI over the existing standards.
The Advanced Power Management (APM) facility control's the power usage of a system based on its activity. The APM BIOS is supplied by the (system) vendor and it is specific to the hardware platform. An APM driver in the OS mediates access to the APM Software Interface, which allows management of power levels.
There are four major problems in APM. Firstly, power management is done by the (vendor-specific) BIOS, and the OS does not have any knowledge of it. One example of this, is when the user sets idle-time values for a hard drive in the APM BIOS, that when exceeded, it (BIOS) would spin down the hard drive, without the consent of the OS. Secondly, the APM logic is embedded in the BIOS, and it operates outside the scope of the OS. This means users can only fix problems in their APM BIOS by flashing a new one into the ROM; which, is a very dangerous procedure, and if it fails, it would leave the system in an unrecoverable state. Thirdly, APM is a vendor-specific technology, which, means that there is a lot or parity (duplication of efforts) and bugs found in one vendor's BIOS, maybe not be solved in others. Last but not the least, the APM BIOS did not have enough room to implement a sophisticated power policy, or one that can adapt very well with the purpose of the machine.
Plug and Play BIOS (PNPBIOS) was unreliable in many situations. PNPBIOS is 16-bit technology, so the OS has to use 16-bit emulation in order to ``interface'' with PNPBIOS methods.
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the
documentation
before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.