ACPI Compliance and Implementation Tracking

This ticket serves as a checklist towards OS compliance with the ACPI standard. The following table lists the required implementations listed in the Advanced Configuration Power Interface (ACPI) Specification, Version 6.2 section 1.7.3

⛽ - Not Yet Implemented

⚠️ - Partially Implemented

🟢 - Fully Compliant

❓ - Tim needs to compare the code against the standard to determine the state of this.

Feature	Status	Notes	Issue
INT 15H, E820H - Query System Address Map interface	❓
EFI GetMemoryMap() Boot Services Function	❓
Find and consume the ACPI System Description Tables	⚠️	[1]
Implementation of AML Interpreter supporting all defined AML Grammar Elements	⚠️	[2]
Implement ACPI Event Programming Model	❓
Enumerate and Configure Motherboard devices described in ACPI Namespace	❓
Implement Embedded Controller Device	❓
Implement GPE Block Device	❓
Implement Module Device	❓
Implement ACPI thermal model	❓
Acquisition/Release of Global Lock	❓
OS Directed Power Management	❓

[1] There is some ACPI table support in the kernel, mostly for boot-time initialization. This is separate from the larger ACPI functionality required. Once we have ACPI table support in the drivers, we can consider merging some of that code back into the kernel. Current driver support for ACPI is the ability to read ACPI tables and publish raw hex data as /scheme/acpi/tables/{table id}. I would like to see the following work done:

• Refactor the crate github.com/rust-osdev/acpi - it currently requires tables to be read from physical memory using a "handler". It should be refactored so there is an implementation that can work with a local copy of the tables, and the changes should be upstreamed. The refactoring should (if possible) not break the current API, but Isaac Woods is open to breaking the API if necessary.
• Write a Redox-specific crate that can be used by a driver task to read a table from /scheme/acpi/tables and provide an intelligent ACPI wrapper for the data.

[2] The AML support is based on the crate github.com/rust-osdev/acpi/aml. It provides an interpreter. However, if the interpreter encounters an error, it gives up. Any definitions that have been parsed successfully are available, but nothing after that. I forked the AML crate, but the rust-osdev version is now ahead of my fork, and we can move back to the upstream. The parser currently quits on one of the bitfield types. Work is required to parse more real-world AML and upstream the changes, but it is getting close to completion AFAIK. It is an interpreter only, so some parsing errors will only occur when the code is being executed (functions are not parsed until called).