os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Make some changes to the ACPI section:

Browse source 
- Document the ``Shortcomings'' of APM in the ACPI section.
	  This was missed when the section was originall committed.

	- Change section title to: ``Power and Resource Management''
	  because it is a bad idea to use acronyms and abbreviations
	  in a chapter or section title, as it can lead to confusion.

	- While I am there, add a missing </sect2> tag.

Approved by: des (mentor)
This commit is contained in:
Hiten Pandya 2003-05-21 23:21:34 +00:00
parent b87eb401a3
commit 4c44b661aa
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=17057
1 changed files with 39 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
en_US.ISO8859-1/books/handbook/config/chapter.sgml
View file

@ -2108,7 +2108,7 @@ kern.maxfiles: 2088 -> 5000</screen>
</authorgroup>
</sect1info>
<title>ACPI and FreeBSD</title>
<title>Power and Resource Management</title>
<para>It is very important to utilize hardware resources in an
efficient manner. Before <acronym>ACPI</acronym> was introduced,
@ -2143,6 +2143,44 @@ kern.maxfiles: 2088 -> 5000</screen>
prior to the introduction of <acronym>ACPI</acronym>. <acronym>ACPI</acronym>
is the direct successor to <acronym>APM</acronym> (Advanced Power
Management).</para>
</sect2>
<sect2 id="acpi-old-spec">
<title>Shortcomings of Advanced Power Management (APM)</title>
<para>The <emphasis>Advanced Power Management (APM)</emphasis>
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 <emphasis>APM Software Interface</emphasis>,
which allows management of power levels.</para>
<para>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 could 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,
may 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 to the purpose of the
machine.
<para><emphasis>Plug and Play BIOS (PNPBIOS)</emphasis> was
unreliable in many situations. PNPBIOS is 16-bit technology,
so the OS has to use 16-bit emulation in order to
<quote>interface</quote> with PNPBIOS methods.</para>
<para>The FreeBSD <acronym>APM</acronym> driver is documented in
the &man.apm.4; manual page.</para>
</sect2>
<sect2 id="acpi-config">
<title>Configuring <acronym>ACPI</acronym></title>