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.
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.