Prepare for stabilisation of the acpi crate#70
Conversation
We turn the virtual addresses returned from this function into references without checking their validity, and so this is unsafe.
This makes it not-a-breaking-change to add new interrupt models in the future, and isn't a big onus on users as they'll likely want a wildcard pattern anyway, as not all interrupt models will be supported on their architecture anyway.
The later x2APIC extended the processor UID to a 4-byte field. We want to use the same representation for that, so simply use `u32` and cast for the old single-byte entries.
|
Pretty minor point, but I wonder if it's worth using the address types from |
While most people seem to be using this crate exclusively on x86_64, there are ARM64 and (I believe) RISC-V systems that either use ACPI or have expressed that they will in the future. It seems like a bad idea to tie
I totally concede that the address handling in So I don't think we do anything wrong here - we use |
|
That sounds totally reasonable. I had a quick google for ACPI on other architectures and didn't find anything, but if you're right that it is used outside of x86_64 then that all makes sense. |
These take potentially-incorrect physical addresses and dereference them, so should definitely be unsafe. This creates warnings about nested unsafe blocks but there are imminent plans to make that accepted so I'm leaving it to reduce churn.
|
Okay, nobody has raised concerns about this so I'm going to go ahead and merge this :) bors r+ |
|
Build succeeded: |
|
Published as |
2 participants
The
acpicrate is nearing the point where I'd like to get it stabilised and publish av1.0.0version. This PR will make a few breaking changes for either correctness or future-proofing for the stuff that isn't yet implemented (e.g. the x2APIC) - I'd be interested in getting people's feedback on both the idea of stabilisation, and whether they think any other changes should be made to the crate before stabilisation.Note that we're not stabilising the
amlcrate at this time.cc @rust-osdev/acpi @64 @phil-opp