Hi all!
uACPI is an ACPI implementation (including an AML interpreter and other components) that aims to be easy to port and integrate.
Project on GitHub: https://github.com/UltraOS/uACPI
Current state of the project
- A well-tested interpreter fully supporting all of AML
- A fully implemented resource subsystem supporting all existing descriptors
- Lots of API already available, this includes sleep/reset, device search, namespace management, opregion/notify handlers, gas read/write, pci routing, interrupt model
- Works on all real hardware tested so far (about 8 different computers), and all VMs. This includes namespace initialization, reading battery state, shutting down and rebooting
More details in the README: https://github.com/UltraOS/uACPI?tab=re ... he-project
Project goals
- Perfect compatibility with the Windows NT ACPI interpreter
- Addressing some of the fundamental design flaws of ACPICA: the global interpreter lock, unsafe object lifetimes, NT incompatibility (reference semantics, implicit-casts, etc)
- Simplifying code by embracing AML designed for the NT ACPI interpreter, instead of trying to work around it (see: ACPICA two-pass package named object resolution)
- Ease of integration and development
Some code examples & more details in the README: https://github.com/UltraOS/uACPI?tab=re ... ver-acpica
A reddit post by me showcasing the interpreter on real hardware: https://www.reddit.com/r/osdev/comments ... _hardware/
Thanks!
uACPI, a portable and easy-to-integrate ACPI implementation
Re: uACPI, a portable and easy-to-integrate ACPI implementat
Excellent goals! I particularly like that the instructions for building it without CMake are just 2 lines. Bookmarked.
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
Re: uACPI, a portable and easy-to-integrate ACPI implementat
An update on the state of the project:
- uACPI now has a fairly complete event subsystem for fixed and general purpose events
- Added support for gracefully skipping opcodes attempting to create duplicate named objects during namespace load
- A bunch of small improvements and various bug fixes, removed strtoull os dependency, now shipping own implementation
- We have tested a lot more computers since, the number is probably close to 20 if not more at the moment, all working just fine!
- uACPI is now the official ACPI subsystem used by the managarm operating system: https://github.com/managarm/managarm
- uACPI now has a fairly complete event subsystem for fixed and general purpose events
- Added support for gracefully skipping opcodes attempting to create duplicate named objects during namespace load
- A bunch of small improvements and various bug fixes, removed strtoull os dependency, now shipping own implementation
- We have tested a lot more computers since, the number is probably close to 20 if not more at the moment, all working just fine!
- uACPI is now the official ACPI subsystem used by the managarm operating system: https://github.com/managarm/managarm
Re: uACPI, a portable and easy-to-integrate ACPI implementat
Interesting. How does it compare in executable size to ACPICA? What does it require from the runtime library? Does it work for a 32-bit protected mode kernel?
Re: uACPI, a portable and easy-to-integrate ACPI implementat
I haven't measured, but it's ~20k loc of C code, so that should give you an ideardos wrote: How does it compare in executable size to ACPICA?
A few very common libc functions (memcpy, strcmp, ...) + snprintf. Besides that, kernel API like map/unmap, alloc/free, mutexes, ticks, etc.rdos wrote: What does it require from the runtime library?
This is not something I've tested personally, but there aren't any places in code that assume 64-bit at least as far as I'm aware, so might just workrdos wrote: Does it work for a 32-bit protected mode kernel?
Re: uACPI, a portable and easy-to-integrate ACPI implementat
Yet another project state update!
- Dynamic table loads from AML via (Load/LoadTable) are no longer recursive (they are in ACPICA even to this day!)
- Fixed a bunch of bugs/missing error checks found via fuzzing
- Sped up name string parsing
- Added a bunch of new tests
- Dynamic table loads from AML via (Load/LoadTable) are no longer recursive (they are in ACPICA even to this day!)
- Fixed a bunch of bugs/missing error checks found via fuzzing
- Sped up name string parsing
- Added a bunch of new tests
Re: uACPI, a portable and easy-to-integrate ACPI implementat
uACPI now has a page on osdev wiki! https://wiki.osdev.org/UACPI
Since the last update I also:
- Added a highly requested UACPI_SIZED_FREES mode, which makes all frees include a size argument
- Made 32-bit builds first class citizen (now run 32-bit CI for every commit as well)
- Did some more fuzzing thanks to the help from a friend, this time against 500 publicly available real hardware AML blobs
- Fixed a few important bugs (we no longer have any crashes when fuzzing! perhaps needs longer sessions)
- Reworked secondary table loading to include PSDTs and made failures non-critical
- Added a more verbose log level (with some extra interpreter bytecode tracing on top)
Since the last update I also:
- Added a highly requested UACPI_SIZED_FREES mode, which makes all frees include a size argument
- Made 32-bit builds first class citizen (now run 32-bit CI for every commit as well)
- Did some more fuzzing thanks to the help from a friend, this time against 500 publicly available real hardware AML blobs
- Fixed a few important bugs (we no longer have any crashes when fuzzing! perhaps needs longer sessions)
- Reworked secondary table loading to include PSDTs and made failures non-critical
- Added a more verbose log level (with some extra interpreter bytecode tracing on top)
Re: uACPI, a portable and easy-to-integrate ACPI implementat
Been a while since the last update, quite a lot has been done:
- uACPI is now fully self-contained by default, only kernel_api.h needs to be implemented by the host
- Implemented support for managing the global ACPI firmware lock (for locked fields, _GL acquires, as well as public API)
- Added an interface management subsystem (controlling what features/vendor strings are reported as supported via _OSI)
- Implemented While loop timeouts, it's no longer possible to hang the interpreter from AML
- All of the publicly available (354) AML blobs are now tested against uACPI on every commit with ASAN+UBSAN in both 32 and 64 bit modes, this executes the blobs and runs all existing _STA/_INI/_HID/_CID/_UID/_CLS/_CRS/_PRS methods
- A bunch of constness correctness for public API
- Simplified a bunch of APIs to make language interop easier
- A whole bunch of bug fixes
- Added tons of code examples to the osdev wiki page
With this, uACPI is very close to being a finished library at its 1.0 release and API stabilization.
Pretty much the only critical piece currently missing is general thread safety for public APIs + interpreter.
I'm also considering adding a few more convenience helpers/APIs, but will see about that.
- uACPI is now fully self-contained by default, only kernel_api.h needs to be implemented by the host
- Implemented support for managing the global ACPI firmware lock (for locked fields, _GL acquires, as well as public API)
- Added an interface management subsystem (controlling what features/vendor strings are reported as supported via _OSI)
- Implemented While loop timeouts, it's no longer possible to hang the interpreter from AML
- All of the publicly available (354) AML blobs are now tested against uACPI on every commit with ASAN+UBSAN in both 32 and 64 bit modes, this executes the blobs and runs all existing _STA/_INI/_HID/_CID/_UID/_CLS/_CRS/_PRS methods
- A bunch of constness correctness for public API
- Simplified a bunch of APIs to make language interop easier
- A whole bunch of bug fixes
- Added tons of code examples to the osdev wiki page
With this, uACPI is very close to being a finished library at its 1.0 release and API stabilization.
Pretty much the only critical piece currently missing is general thread safety for public APIs + interpreter.
I'm also considering adding a few more convenience helpers/APIs, but will see about that.