Subsystems

A subsystem owns or coordinates a runtime capability installed by a final Xila binary. It manages state/lifecycle or the unavoidable process-global integration of an active runtime service. It is not simply a crate with mutable types.

Foundation services

• Task: task identity and execution registry. task crate.
• Users: user and group management. users crate.
• Time: runtime time source and startup clock. time crate.
• Memory: installed allocator integration and allocation capabilities. memory crate.
• Log: installed logging service and global logger boundary. log crate.

Coordinating services

• Virtual file system: mounted namespace, permissions and dispatch. virtual_file_system crate.
• Network: interface stacks, runners and socket services. network crate.
• Graphics: LVGL, windows, displays, input and events. graphics crate.

Boundaries

Subsystems use contracts from libraries and concrete drivers. The final binary constructs them in a valid dependency order and passes managers to executables. The allocator, logger and LVGL remain partially process-global by design.

C ABI contracts are libraries. Wasmi and guest bindings belong to the WASM executable rather than representing new independent subsystems.

How to read each subsystem reference

Every subsystem page is intended to serve as an engineering reference, not just an overview. Read its public contract first (what consumers may depend on), then its implementation and ownership (who constructs it, which resources it retains, and how it is synchronized), then its failure and portability boundaries. Use the Rustdoc and source links for exact signatures; implementation details can change without changing the contract.

Subsystem	Core responsibility	Key integration boundary
Task	Task identity, metadata, spawn and join	Embassy executors and user context
Users	User/group identifiers and memberships	Authentication and VFS authorization
Time	Read current clock and startup-relative duration	Direct character-device clock
Memory	Allocation contract and global allocation	Target allocator and capabilities
Log	Global logging facade and filtering	Backend LoggerTrait
Virtual file system	Namespace, mounts, permissions and handles	File-system and device contracts
Network	Interface stacks and socket services	smoltcp, driver and VFS control
Graphics	LVGL lifecycle, display/input and windows	Target display/input drivers and guest events

Stability and completeness

These pages describe the current Core implementation, not a promise that every interface is stable. In particular, the time manager's startup-relative reading is not a monotonic clock, the Users credential check is not an authentication mechanism, and logging initialization is process-global. Consult the individual pages for the consequences and known limitations.

For changes affecting application-facing interfaces, check both the subsystem and the corresponding library contract, driver or executable integration.