Move to new namespace representation #72
Merged
Conversation
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
This needs to be carefully considered, but I think will reduce the number of heap allocations (and also overall heap burden) on normal workloads. This has not yet moved all the searching and insertion methods over to the new representation yet, so won't build.
…amespace In the new namespace, devices and scopes need to be registed as "levels" before objects can be added to them. Devices also no longer exist as `AmlValue`s, as they don't exist as leaf objects.
* Correctly handle trying to add the root level * Change algorithm so we don't have to differentiate between levels on the root level, and levels on sub-levels * Correctly emit error in cases of colliding levels * Change error emitted to be better * Efficiently normalise path instead of making it the caller's problem
This actually prints the namespace in a much more useful format than we could've before with the old data structure, indenting each level and printing the objects nicely collected under their parents.
Turns out we had a OEM ID that was too long (must be a maximum of 6 chars) but the old version of the compiler never picked it up. Also changed where PCI0 is expected to be in the namespace to test nested scopes.
WARNING: this breaks semver compatibility and so will need a new major version.
We literally get hundreds of `DefPackage`s in `_PRT` objects, so it uses up an unreasonable amount of space and indentation to print these on `Scopes`.
* Comments would appear under module `aml`, but `comment_scopes` would appear under `aml::parser`, which throws off the indentation. * Scopes that aren't printed because they don't meet the verbosity setting still contributed to the indent level, so stuff would be massively indented by scopes that aren't printed.
Legacy `Processor` objects can contain sub-objects, but also contain data, so we need to define both a value and a namespace level.
I'm not sure if this is the right path to go down, but we can always rip it out if it's not. ACPI 1.0 seems different enough that I think it's worth separating out as a 'legacy' mode.
For whatever reason, rustfmt keeps trying to wrap comments to way shorter than we've told it to. This is boring, so let's tell rustfmt to go away for now.
They are already at the correct indent before adding another scope.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 PR moves to a new representation of the namespace that stores values in a more efficient and, hopefully, also easier to query data structure. It also makes various changes to support this new representation.
cc @rust-osdev/acpi if anyone is interested, feel free to review / leave comments