Rewrite acpi crate and entire AML interpreter#246
Merged
IsaacWoods merged 113 commits intorust-osdev:mainfrom Aug 18, 2025
Merged
Rewrite acpi crate and entire AML interpreter#246IsaacWoods merged 113 commits intorust-osdev:mainfrom
acpi crate and entire AML interpreter#246IsaacWoods merged 113 commits intorust-osdev:mainfrom
Conversation
I don't really understand why this had a lifetime instead of constructing the slice for the lifetime of `self`, but this cleans stuff up a fair bit both in the library and for users.
…e`, `DefMethod`, `DefExternal`
Still need to do a bunch of bit fiddling stuff to facilitate actually reading and storing to them.
To match NT's behaviour, we should just evaluate a namestring within a package definition to a string object. Also handles this change in PRT handling.
This is required for various special address space types (e.g. the PCC)
This was unneeded complexity in the end and came unstuck when we realised the library needs to do I/O port accesses for register accesses. Users can just not implement parts of the API they're unable/will not use and deal with the consequences. Also catches changes to cache a mapping to the FACS in the AML interpreter.
This requires the AML interpreter to have access to the fixed hardware registers, and so changes the convenience initialization method to take a `AcpiPlatform` instead of just the tables. I think this is fine in the long run - users can still manually construct an interpreter if needed.
Member
Author
|
🚀 Further work will be needed to support remaining opcodes, support correct behaviour of various existing bits of the library, and other bits. These can hopefully be done as non-breaking changes in the first instance. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This (entirely too large) PR represents work I've been doing over the last few months to address a large number of bugs in both the
acpiandamlcrates, and generally improve the quality of the library. While this work is nowhere near complete, it represents the library getting back to a point where I think it is reasonable for projects to use it (in that it is more correct than the current interpreter in all circumstances), and is already too unwieldy to rebase against other PRs that are waiting for review/merging.For contributors awaiting PRs being merged, I apologise for this derailing your contributions, and I am happy to assist in rebasing your changes/creating new patches with you credited as authors. I will review current PRs when I have time.
Summary of changes
Firstly, the
acpicrate has undergone major reworking to simplify logic surrounding table mapping and RSDT enumeration. This should fix #245.Previous work on allowing fallible allocations has been removed, as it added significant complexity for little real-world gain at this time - if the ecosystem around fallible allocation in Rust improves in the future, I'm not against re-adding these capabilities. The split between the portion of the library that can be used without an allocator vs requiring one has been made clearer, with allocating methods being moved under the higher-level
platformmodule.This PR also deprecates the
amlcrate, bringing the interpreter into theacpicrate under a feature-flag. This simplifies the most common use-cases of the library, and was effectively required for ergonomic handling of some AML operations that require us to handle static ACPI tables. Future work with the ACPI event system will likely require closer coupling between the previously-separate parts of the library, as well.I am imagining that these changes will be published as
acpi v6.0.0, with theamlcrate being marked as deprecated and receiving no future updates.Remaining tasks
AcpiHandlervsacpi::aml::Handler- do we want to merge them, makeAcpiHandlera supertrait (perhaps being renamedRegionMapperor similar as this is the only functionality it needs to provide)?GenericAddressto have arbitrary field widths - apparently required by the PCC (see acpi: add support for PCC table #233)DefVarPackageDefToBufferDefToIntegerDefToStringDefToDecimalStringDefToHexStringTasks for future PRs
I have decided to push various functionality to future PRs to get this merged as it is a strict improvement on current
main.DefMatchDefLoadDefLoadTableDefDataRegionDefStorevsDefCopyObjectDefNotifyetc)Feedback
I would welcome feedback on the new APIs, crate layout, or changes I should consider before publishing a new major version of
acpi. I particularly welcome feedback + bug-reports from people who have integratedacpiinto a kernel or other project.cc @rw-vanc - I would be interested in any concerns re Redox moving to the new version of the crate, and any further work you'd be interested in.
cc @usadson - this should fix #245. Thank you for your report.