A speciális energia- és konfigurációs illesztő felület (Advanced Configuration and Power Interface, avagy ACPI) gyártók egy csoportja által létrehozott szabvány, amely a hardveres erőforrások és az energiagazdálkodás egységes felületét rögzíti (innen a neve). Döntő szerepet játszik a Beállítások és az energiagazdálkodás operációs rendszerek áltai vezérlésében, vagyis segítségével az operációs rendszer még nagyobb mértékben és rugalmassággal tudja irányítani ezeket a lehetőségeket. A modern operációs rendszerek az ACPI felbukkanásával "kitolták" a jelenleg meglevő Plug and Play felületek korlátait. Az ACPI az APM közvetlen leszármazottja.

A Fejlett energiagazdálkodás (APM) a rendszer által felhasznált energiát annak elfoglaltsága alapján vezérli. Az APM-et támogató BIOS-t a (rendszert) gyártó állítja elő és az adott hardverplatformra jellemző. Az APM operációs rendszerben levő meghajtója hozzáférést biztosít az APM szoftveres felületéhez, amivel lehetőség nyílik az energiaszintek kezelésére. Az APM-et 2000 előtt és körül még mindig használták egyes rendszerek gyártásánál.

Az APM használata négy nagyobb gondot rejt magában. Először is, az energiagazdálkodást a (gyártófüggő) BIOS végzi el, és az operációs rendszernek erről semmilyen ismerete nincsen. Ennek egyik példája az, amikor a felhasználó az APM-et ismerő BIOS-ban beállítja a merevlemezek automatikus kikapcsolásának idejét, majd amikor ez letelik, a BIOS az operációs rendszer tudta nélkül egyszerűen leállítja a lemezt. Másodszor: az APM működését a BIOS-ban programozták le, és teljesen az operációs rendszer hatáskörén túl tevékenykedik. Ez azt jelenti, hogy a felhasználó csak úgy tudja korrigálni az APM-es BIOS-ok problémáit, ha frissíti az alaplapi ROM-ot. Ez viszont egy nagyon kockázatos folyamat, amelynek hibája révén a rendszerünk helyrehozhatatlan állapotba kerülhet. Harmadszor: az APM alapvetően egy gyártófüggő megoldás, ami azt vonja maga után, hogy sok az átfedés (ugyanazt valósítják meg több módon), és ha az egyik gyártó BIOS-ában hibát találnak, akkor a másikéban az nem feltétlenül javítható. Végül, de nem utolsósorban, az APM alapú BIOS-okban nincs elég hely az igazán kifinomult energiagazdálkodási sémák vagy bármi más kialakítására, amivel a felhasználók képesek lennének az igényeikhez alakítani a számítógépet.

A Plug and Play BIOS (PNPBIOS) sok szempontból megbízhatatlannak bizonyult. A PNPBIOS ráadásul egy 16 bites megoldás, ezért az operációs rendszereknek 16 bites emulációt kell használniuk a PNPBIOS eszközeinek "eléréséhez".

A FreeBSD APM meghajtójának dokumentációját az apm(4) man oldalon találjuk.

Az acpi.ko meghajtó alapértelmezés szerint a loader(8) segítségével töltődik be, és ne is fordítsuk bele a rendszermagba. Ezt azzal tudnánk magyarázni, hogy modulokkal könnyebb dolgozni, például ha a rendszermag újrafordítása nélkül egy másik acpi.ko modult akarunk használni. Ezzel a lényegében a tesztelés is egyszerűbbé válik. Másik magyarázat, hogy a rendszer ACPI támogatása nem minden esetben működik rendesen. Ha a rendszer indítása során valamilyen problémát tapasztalunk, akkor próbálkozzunk meg az ACPI kikapcsolásával. Ezt a meghajtót nem lehet és nem is szabad kidobni a memóriából, mivel a hardverrel a rendszerbuszon keresztül tartja a kapcsolatot. Az ACPI a hint.acpi.0.disabled="1" sor megadásával kapcsolható a /boot/loader.conf állományban vagy a loader(8) parancssorában.

Az ACPI és az acpiconf(8) használatával a rendszerünk készenléti módba helyezhető az -s valamint az 1-5 paraméterek megadásával. Ezek közül is a legtöbb felhasználó számára csak az 1 vagy a 3 (állapot mentése a fizikai memóriába) érdekes. Az 5 opció egy szoftveres kikapcsolást eredményez, ehhez hasonlóan:

# halt -p

A további opciók a sysctl(8) man oldaláról érhetőek el. Ezen kívül még olvassuk el az acpi(4) és acpiconf(8) man oldalakat is.