integration with open-source UEFI project at [Microsoft]

[berlin-with0ut-return]

i'm part of an open-source project at Microsoft that is implementing UEFI in Rust (primarily DXE as of now).
docs
repo

in particular i've been working on an implementing of spec-compliant ACPI protocols in Rust. i've implemented most of the functionality related to manipulating tables themselves (ie the ACPI Table Protocol ). you can see that implementation here.

i'm now looking into implementing the parts of the ACPI SDT Protocol that deal with parsing and patching AML. this would be functionality like GetOption, SetOption, GetChild etc (with better Rust-y interfaces). i think there is a decent amount of overlap between our goals and yours, especially in the low-level parsing code (for example, our Rust AML implementation would also have to parse opcodes and pkg_lengths).

in the short term my primary goal would be to finish up the SDT protocol but we've discussed long-term goals of providing application-side AML interpretation/execution as well. as such i wanted to start a conversation to see how much we could repurpose/modify parts of the existing acpi crate for our purposes. (for example, can we expose lower-level parsing for use in our firmware AML implementation, can we modify parts of the existing acpi code to work with our ACPI table definitions?, etc)

leaving this very open-ended as i am personally not an expert in ACPI. happy to answer any questions; i can also connect you with more senior leadership (i am not the primary owner of Patina.)

[martin-hughes]

Hi @berlin-with0ut-return, sorry for the slow reply - let me bump this over to discussions.

[martin-hughes]

Hi again!

So first up - I'm not the crate owner, but I'm happy to take questions and anything that's beyond me I'll bump to Isaac.

My impressions are:

• Our goals are related, but probably opposite - we're very much on the consumer side, whereas I think you're on the producer side? (see also Intel/Amazon Rusty AML parser #215)
• Our objective is to keep the crate as a consumer rather than starting to expose producer utilities as well (see the extended discussion in Directly test a stream of opcodes #298 for example)
  • Personally, I think I'd be OK if acpi depended on a no_std "AML utilities" crate... but it's a fine line between that and writing a full AML parser!
  • I guess such a crate could even live within this repo if Isaac were happy with it.
• If you see an interface that would be useful to you then please raise a PR (or discuss it here first if it might be controversial) - for the areas where you're parsing the AML I think we would be a dependency of yours. I'm not sure if there's a scenario where you would be our dependency.

Anyway, yes - if you see anything more detailed you'd like to work on then please feel free to open discussions or raise PRs.