Crate acpi[−][src]
Expand description
A library for parsing ACPI tables. This crate can be used by bootloaders and kernels for architectures that support ACPI. This crate is not feature-complete, but can parse lots of the more common tables. Parsing the ACPI tables is required for correctly setting up the APICs, HPET, and provides useful information about power management and many other platform capabilities.
This crate is designed to find and parse the static tables ACPI provides. It should be used in conjunction with
the aml
crate, which is the (much less complete) AML parser used to parse the DSDT and SSDTs. These crates
are separate because some kernels may want to detect the static tables, but delay AML parsing to a later stage.
This crate requires alloc
to make heap allocations. If you are trying to find the RSDP in an environment that
does not have a heap (e.g. a bootloader), you can use the rsdp
crate. The types from that crate are
compatible with acpi
.
Usage
To use the library, you will need to provide an implementation of the AcpiHandler
trait, which allows the
library to make requests such as mapping a particular region of physical memory into the virtual address space.
You then need to construct an instance of AcpiTables
, which can be done in a few ways depending on how much
information you have:
- Use
AcpiTables::from_rsdp
if you have the physical address of the RSDP - Use
AcpiTables::from_rsdt
if you have the physical address of the RSDT/XSDT - Use
AcpiTables::search_for_rsdp_bios
if you don’t have the address of either, but you know you are running on BIOS, not UEFI - Use
AcpiTables::from_tables_direct
if you are using the library in an unusual setting, such as in usermode, and have a custom method to enumerate and access the tables.
AcpiTables
stores the addresses of all of the tables detected on a platform. The SDTs are parsed by this
library, or can be accessed directly with from_sdt
, while the DSDT
and any SSDTs
should be parsed with
aml
.
To gather information out of the static tables, a few of the types you should take a look at are:
PlatformInfo
parses the FADT and MADT to create a nice view of the processor topology and interrupt controllers onx86_64
, and the interrupt controllers on other platforms.AcpiTables::platform_info
is a convenience method for constructing aPlatformInfo
.HpetInfo
parses the HPET table and tells you how to configure the High Precision Event Timer.PciConfigRegions
parses the MCFG and tells you how PCIe configuration space is mapped into physical memory.
Re-exports
pub use crate::fadt::PowerProfile;
pub use crate::hpet::HpetInfo;
pub use crate::madt::MadtError;
pub use crate::mcfg::PciConfigRegions;
pub use crate::platform::interrupt::InterruptModel;
pub use crate::platform::PlatformInfo;
Modules
Structs
Describes a physical mapping created by AcpiHandler::map_physical_region
and unmapped by
AcpiHandler::unmap_physical_region
. The region mapped must be at least size_of::<T>()
bytes, but may be bigger.
Enums
Traits
An implementation of this trait must be provided to allow acpi
to access platform-specific
functionality, such as mapping regions of physical memory. You are free to implement these
however you please, as long as they conform to the documentation of each function. The handler is stored in
every PhysicalMapping
so it’s able to unmap itself when dropped, so this type needs to be something you can
clone/move about freely (e.g. a reference, wrapper over Rc
, marker struct, etc.).
All types representing ACPI tables should implement this trait.