Red Bear OS 8dd8fb3b20 acpid: harden AML handler — bounded stall, mutex owner-check, static cache, panic-free path, observability
Five daemon-local hardening items on top of the AML-mutex fix. acpid is
single-threaded and serves the `acpi` scheme on the same thread that
evaluates AML, so any way it can stall or die stalls or kills every
consumer. These reduce or bound each such way (verified against
local/reference/linux-7.1 ACPICA):

- stall(): refuse >255us and warn >100us instead of an unbounded CPU
  busy-spin on the serving thread (ACPICA exsystem.c:129-147). The spec
  caps Stall at 100us; a long busy-spin here would delay scheme requests.

- AML mutex release(): a release of a not-currently-held mutex, or by a
  non-owning thread, is now logged (ACPICA AE_NOT_ACQUIRED / owner
  mismatch, exmutex.c:287,376) rather than silently decrementing depth.

- Static processor-method cache: _PSS/_PSD/_CST/_CPC are fixed after boot
  but cpufreqd polls them; cache the first evaluation so later reads never
  re-run the AML interpreter under the global lock. Removes acpid's
  dominant recurring head-of-line source. Dynamic methods are not cached.

- Panic-free scheme path: every release_global_lock().expect(...) on the
  AML-evaluation path is now log-and-continue, and a result.ok()?.unwrap()
  that panicked on Ok(None) (absent method) is now `?`. A scheme-daemon
  panic kills the `acpi` scheme and wedges every consumer.

- Observability: log AML evaluations >=50ms and mutex-acquire timeouts —
  the early-warning signal before a stall becomes a wedge.

Context: the residual under-load boot wedge is NOT in acpid (a mutex-only
baseline wedges identically under load); it is head-of-line blocking in
the single-threaded initnsmgr. See
local/docs/INIT-NAMESPACE-MANAGER-SCALABILITY-PLAN.md and
local/docs/INITNSMGR-CONCURRENCY-DESIGN.md.
2026-07-21 08:33:26 +09:00
2025-11-29 19:04:06 +01:00
2025-11-29 19:04:06 +01:00

Base

Repository containing various system daemons, that are considered fundamental for the OS.

You can see what each component does in the following list:

  • audiod : Daemon used to process the sound drivers audio
  • bootstrap : First code that the kernel executes, responsible for spawning the init daemon
  • daemon : Redox daemon library
  • drivers
  • init : Daemon used to start most system components and programs
  • initfs : Filesystem with the necessary system components to run RedoxFS
  • ipcd : Daemon used for inter-process communication
  • logd : Daemon used to log system components and daemons
  • netstack : Daemon used for networking
  • ptyd : Daemon used for pseudo-terminal
  • ramfs : RAM filesystem
  • randd : Daemon used for random number generation
  • zerod : Daemon used to discard all writes and fill read buffers with zero

How To Contribute

To learn how to contribute you need to read the following document:

If you want to contribute to drivers read its README

Development

To learn how to do development with these system components inside the Redox build system you need to read the Build System and Coding and Building pages.

How To Build

It is recommended to build this system component via the Redox build system, you can learn how to do it on the Building Redox page.

To build and test outside the build system, install redoxer then use check.sh script to build or test:

  • ./check.sh - Check build for x86_64
  • ./check.sh --arch=ARCH - Check build for specific ARCH (aarch64, i586, riscv64gc)
  • ./check.sh --all - Check build for all ARCH
  • ./check.sh --test - Check the base system boots up on x86_64

You can also use make install to inspect the content on ./sysroot, or make test-gui to test booting with orbital interactively.

S
Description
RedBear Operating System, based on RedoxOS. Licenced under MIT license.
https://redbearos.org
Readme MIT 18 GiB
Languages
C 37.5%
C++ 37.2%
JavaScript 6.7%
QML 3.4%
HTML 3.2%
Other 11.4%