fbcond

fbcond is the framebuffer console service for EriX.

EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.

Technical requirements are tracked in the EriX requirements, conventions, and project documentation.

See:

• docs for design documents, specifications, and development plans.
• Related architecture repositories for kernel, services, libraries, drivers, and integration tooling.

Purpose of This Repository

This repository implements the EriX fbcon service daemon. Its purpose in EriX is to provide the fbcon service role through explicit IPC and startup authority.

Functionally, it implements the daemon runtime, state model, IPC handling, and validation tests. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• implement the fbcon service runtime and state model
• validate startup authority before accepting IPC requests
• handle bounded service operations through the assigned endpoint set
• keep service behavior, tests, and authority invariants documented

Clean-Room Policy

EriX follows a strict clean-room philosophy:

• No external source code may be copied.
• No external Rust crates are allowed.
• No code generation tools that embed third-party code.
• All code must be authored within the project.

Violations will result in rejection of the contribution.

License

All EriX repositories are licensed under the ISC License.

Development Model

EriX development is modular, deterministic, reproducible, authority-explicit, security-first, and self-hosting oriented.

This repository follows the project roadmap and the validation rules documented in its own roadmap.

Feature model

• fbcond-runtime: base daemon behavior
• fbcond-runtime-framebuffer: framebuffer console mode
• integration feature presets (fbcond-integration-*) select runtime behavior, with optional force-fail test gating

Build and test

cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test

Validation Note

The host/test QUERY_CAP fallback remains cfg-scoped and fbcond now keeps only the direct kind-aware local-cap helper in runtime code, so runtime/release builds stay warning-free.

Required startup delivery has no fixed tick deadline. Runtime callers must use authority-free envelopes; every complete unexpected receipt is retired before rejection, while malformed receipt metadata, terminal receive state, or an undeliverable accepted reply terminates the process for complete CSpace teardown. Kernel-control calls and replies retain their storage through transient backpressure and reject transferred authority.

Root/log/trusted framebuffer records normalize bare carriage returns or linefeeds to CRLF before rendering/readback so serial-style service stamps cannot overwrite earlier framebuffer rows. Write requests use explicit continuation/end flags for multi-packet logical records, so streamed log lines do not gain artificial row breaks between transport chunks.

At the userspace handoff, fbcond resumes the kernel console cursor without clearing or repainting the scanout. Once output reaches the bottom, normal line scrolling shifts the visible text rows upward and clears only the newly exposed final row instead of jumping back to row zero. Records without an explicit foreground color retain the original fbcond green palette.

The immutable PF2 mapping is fully validated and indexed once during startup. Short-lived renderer instances borrow that owned index without copying its lookup table and recheck only their bounded glyph references, avoiding a complete Unicode index scan for every log record.

The optional square-probe integration mode proves framebuffer access through the kernel verification opcode and retained console readback. It has no service-local probe breadcrumb or kernel LOG_STRING debug stub.

Runtime configuration selects framebuffer readback retention explicitly. Packaging authenticates the exact usable prefix of a dedicated page-rounded arena, so fbcond has neither the retired fixed 128-KiB history ring nor allocator access to arena padding. IPC request and reply storage follows the shared 8,192-byte transport contract instead of a private 1-KiB ceiling.

Dynamic Boot Artifact Evidence

The runtime image contract documents fbcond as a dynamic boot artifact. The image build packages the framebuffer console service as an ELF64 x86_64 ET_DYN executable with .erix_dynlink metadata in the signed dynlink-store and mirrors it under /lib/erix/dynlink with its required shared objects.

Startup remains rootd through procd staged dynamic creation before dynlinkd; authority remains the dedicated console endpoint and explicit rootd, logd, and ttyd rendering peers. Dynamic packaging and filesystem mirror records are evidence and launch inputs only; they do not grant filesystem, loader, object-store, service-discovery, provider-bypass, block-device, or dynlinkd authority. fbcond receives only the documented startup endpoints, peers, and capabilities for its role.

Governance Principles

fbcond governance is scoped to framebuffer console rendering and readback service behavior.

The scoped governance rules are:

• It uses only startup-assigned framebuffer, font, and console control authority.
• It keeps rendering state deterministic and readback retention deployment-selected.
• It validates console IPC before mutating screen or history state.
• It does not own input policy or device-driver authority.

Authority Boundaries

• The canonical service endpoint is read/status-only.
• Rootd and logd retain mandatory distinct record-write receivers. The authenticated startup declaration supplies both ttyd terminal/trusted receivers or neither. An omitted pair is checked absent once, then excluded from every runtime receive; partial, present-but-omitted, and uncertain configurations fail before readiness.
• Only the exact ttyd ordinary-terminal route preserves bare carriage returns and decodes fragmented relative CSI A/B/C/D, current-row 2K and caret ?25h/l. Root/log/trusted routes keep literal record rendering and newline rules. The reversible ordinary caret is suspended before another writer paints; malformed CSI cannot become trusted renderer commands.
• Write authority is authenticated by endpoint possession; requests contain no caller-claimed role or source identity.
• Trusted-chrome writes use a fixed renderer-owned foreground, render before acceptance, and never enter ordinary readback. While trusted chrome is active, ordinary writes receive retryable resource exhaustion and cannot overwrite it. An exact empty release record on ttyd's trusted route re-enables ordinary rendering; the release changes arbitration state and does not claim to erase previously drawn pixels.
• fbcond operates only through those exact startup-assigned endpoints and its dedicated kernel console-control capability.
• New authority must be represented in bootstrap/capability validation and integration tests before use.

Contact

Development occurs in EriX organization and discussions happen in issues and design documents.

No decisions are considered valid without documented rationale.

Maintainers can be reached via email: admin@erikinkinen.fi.