logd

logd is EriX's centralized, in-memory logging service. It accepts structured records over IPC, retains them in deterministic service-owned storage, serves cursor-based queries, and mirrors selected records to explicitly authorized console services.

EriX is a clean-room, capability-based microkernel operating system written in Rust. System specifications and development plans live in the docs repository.

Purpose of This Repository

This repository owns the logd runtime, startup validation, log IPC dispatch, retained-record state, console-mirror policy, and repository-local tests.

Its maintained responsibilities are:

• validate the complete startup capability inventory before serving requests;
• take the kernel's retained early records exactly once through the narrow log-control endpoint;
• implement IPC_LOGD_OP_SUBMIT_STRING and IPC_LOGD_OP_QUERY;
• assign monotonic record identifiers and deterministic timestamps;
• retain accepted records in deployment-sized, allocation-free storage;
• mirror eligible records to seriald and fbcond without blocking on an unavailable sink; and
• retire kernel output authority only after the direct-sink handoff succeeds.

The repository does not own kernel policy, service publication, device discovery, durable storage, or unrestricted service discovery.

Clean-Room Policy

EriX follows a strict clean-room policy:

• no external source code may be copied;
• no external Rust crates are allowed;
• no generator may embed third-party code; and
• all implementation code must be authored within the project.

Violations result in rejection of the contribution.

License

This repository is licensed under the ISC License.

Development Model

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

Runtime feature model

• logd-runtime: core daemon behavior;
• logd-runtime-logging: logging client and sink-transport support;
• logd-runtime-serial: direct and replayed seriald output;
• logd-runtime-framebuffer: seriald plus fbcond output; and
• logd-runtime-release-image: retain every accepted record while externally emitting only warnings and terminal readiness evidence.

The matching logd-integration-* features select integration-only entry and failure-injection behavior. logd has no time-service feature: the former feature never contacted timed, so its unused authority and dependency were removed. Records without caller-supplied timestamps use the service's deterministic monotonic counter.

Startup and authority

Normal startup requires:

• the query-only service receive endpoint;
• the narrow kernel log/query primary-control endpoint;
• five producer-specific receive endpoints for rootd, procd, deviced, probed, and drv-serial; and
• send-only seriald and fbcond writer endpoints.

logd neither publishes itself nor receives a naming-directory endpoint. Rootd publishes the query endpoint and delegates every producer and sink endpoint in the validated startup inventory. Runtime request data cannot select, resolve, or materialize a capability.

Startup fails closed unless both the complete declared transfer bundle and the live local capability inventory validate. There is no tuple-only or foundation-order compatibility path. The startup receive rendezvous has no daemon-local deadline; the launcher and external VM harness own lifecycle and scenario duration.

Producer identity and policy authority come from the receive endpoint:

• root's administrative producer may use any valid submit policy;
• deviced may use either no policy or the exact SUPPRESS_KERNEL|INTERNAL_ONLY policy;
• the remaining producers may not request routing policy; and
• no submit request carries or claims a service role.

The runtime scans all query and producer endpoints nonblocking in a fair rotation, then performs one maintenance step and yields when the sweep is empty. Serving one authority partition therefore does not depend on traffic or timer progress at another endpoint.

After a successful reply, the runtime yields before entering outbound sink maintenance. Each turn makes at most one outbound peer call; locally suppressed records consume no peer turn. Each optional mirror makes one nonblocking sink-acceptance attempt. A busy sink leaves the canonical record pending for a later maintenance turn; an accepted call retains its buffer until the authoritative reply arrives. The completed producer can therefore observe its reply before outbound work and an unavailable sink cannot monopolize the service loop. Once fbcond is ready, ordinary framebuffer replay is eligible in these bounded post-reply turns instead of waiting for terminal readiness. Interactive startup output therefore remains visible while the initial shell is still running; the terminal barrier remains the final visibility check.

Kernel early-log ingestion, direct output, and output-retirement operations use one shared retained kernel-control exchange. Pre-acceptance backpressure has no local attempt or time ceiling, and accepted request storage remains exclusively owned until the authoritative kernel reply arrives.

Records submitted by deviced always defer their serial mirror until a later maintenance turn. This preserves the record while preventing the dependency cycle deviced -> logd -> seriald -> deviced during driver and HAL startup. While that cycle guard is active and the direct serial path is not ready, logd may mirror an externally eligible record through its own retained bootstrap kernel route even during the framebuffer-preference window. The authenticated producer does not request or receive authority to select that fallback.

The daemon retains its own startup record as internal evidence. Startup never calls a console sink: sink traffic begins only after the corresponding service has reported readiness and the delegated endpoint has been validated.

Sink endpoints remain usable only while a fresh local-capability query confirms an endpoint with SEND. Transport or semantic write failure clears the runtime cache; authority remains confined to the startup-delegated local slot. A sink write is complete only when its typed result is OK and its reported byte count exactly equals the requested nonempty chunk; short and over-reported responses preserve the canonical replay obligation and cannot certify output.

Log IPC contract

IPC_LOGD_OP_SUBMIT_STRING (0x514) accepts chunked, NUL-terminated records. Policy flags control kernel routing, external suppression, and internal verification records. IPC_LOGD_OP_QUERY (0x515) returns retained records by cursor with severity, source, timestamp, and text filters. IPC_LOGD_OP_READ_STATUS (0x516) reports configured capacities, current occupancy, pending sink obligations, and retention-evicted delivery counts.

Every record occupies one descriptor and one validated range in the canonical retained-byte store. Long records are streamed to sinks in wire-sized chunks. Serial emission expands bare linefeeds to CRLF; retained text is unchanged. Framebuffer chunks carry explicit continuation and end-of-record flags.

The selected runtime configuration supplies retained-record, pending-submission, and retained-byte capacities. Packaging authenticates the target layouts, expands one dedicated page-aligned NOBITS arena to the exact page-rounded size, patches the capacity metadata, and signs the resulting executable. Logd carves that arena into canonical record descriptors, incomplete submissions, exceptional terminal-delivery state, and message bytes once at entry. It retains no allocator, and alignment or page-rounding padding cannot be repurposed.

Serial and framebuffer replay obligations are flags on canonical records, not duplicate payload queues. Retention-policy eviction proceeds even when a sink is unavailable and increments the dropped-delivery counter for each discarded obligation, so a failed sink cannot impose backpressure on every producer.

During handoff, logd destructively takes the kernel's early records into its retained stream. The kernel therefore retains neither transferred storage nor a replay cursor after the handoff. Authenticated deployment storage must hold at least one maximum-width kernel record; a transfer/protocol/storage failure fail-stops startup instead of silently discarding a consumed record. Kernel framebuffer and generic direct-log routes are disabled through the narrow primary-control endpoint only after the corresponding direct sinks are ready. Failed disable calls remain retryable. Terminal readiness is acknowledged only after required sink visibility and kernel-authority retirement have both succeeded.

Build and test

cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-features
RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features

The runtime artifact is an ELF64 x86_64 ET_DYN image with EriX dynamic-link metadata. Packaging records and filesystem mirrors identify launch inputs; they do not grant filesystem, loader, object-store, or dynamic-linker authority.

Governance Principles

logd governance is limited to deterministic log collection, retrieval, and explicitly configured output routing.

• request bodies are validated before state mutation;
• storage exhaustion produces documented deterministic behavior;
• authority is obtained only through the validated startup bundle;
• producer identity and policy come only from the invoked endpoint; and
• compatibility changes update IPC definitions, consumers, tests, and documentation together.

Authority Boundaries

• The primary-control endpoint exposes only kernel log/query operations.
• The public service endpoint accepts queries only.
• Each producer endpoint accepts submissions from one authenticated role.
• Sink authority is confined to the two canonical send-only local slots.
• No record content, role field, feature flag, or artifact path grants authority.

Contact

Development occurs in the EriX organization. Decisions require documented rationale.

Maintainers can be reached at admin@erikinkinen.fi.