named

named is EriX's target-scoped service-discovery daemon.

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 the kernel, bootstrap libraries, service clients, and integration tooling.

Purpose of This Repository

This repository owns the named runtime, its root-authorized publication state, and its target-scoped resolution IPC.

The maintained responsibilities are:

• validate the startup envelope and exact delegated capability inventory
• accept registry seeding, sealing, and publication activation only through the root control endpoint
• expose one resolution endpoint per public target role
• materialize only the endpoint authorized by the invoked resolution scope
• remove invalid or residual publication capabilities
• keep the runtime, state-machine tests, and interface documentation together

named does not create services, authorize private providers, accept self-registration, or perform descriptor-only registry queries.

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.

Current behavior

• Root seeds canonical role/name metadata for the three public targets (timed, irqd, and pagerd) and seals that exact set.
• Root activates a publication only after observing that service's successful startup. The activation call must deliver exactly one kernel-normalized receipt whose root-local source provenance, receiver-local destination, type, and rights match the target's publication policy. timed and pagerd publish their canonical SEND service endpoints. IRQD publishes only its SEND|GRANT LAPIC-timer handler endpoint; its administrative and COM1 endpoints are not discoverable.
• Public callers receive only the SEND|GRANT resolution scopes declared for their role.
• A resolution request carries only its request ID and mandatory destination slot; the invoked endpoint identifies the target.
• Public discovery is limited to timed, irqd, and pagerd.
• Registry storage has one cell per capability ABI target scope, with no unrelated free-entry ceiling and no cell for an unresolvable role.

Build and test

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

Validation uses full commit pins for all EriX dependencies. Integration caches preserve the selected Git object identities, without branch-head fallback or synthetic replacement commits.

Dependencies

• ipc-syscall-x86_64
• lib-bootstrap
• lib-capabi
• lib-ipc

No third-party crates are used.

Runtime features

• named-runtime selects the bare-metal runtime.
• named-integration-smoke enables integration-only runtime evidence.
• named-integration-force-fail injects an integration-only startup failure and must not be enabled in production images.

Dynamic boot artifact evidence

The image build packages named as an ELF64 x86_64 ET_DYN executable with signed dynamic-link metadata and a filesystem mirror. Those records establish artifact identity and dependencies; they do not grant filesystem, loader, object-store, provider, block-device, or discovery authority.

Governance Principles

named governance is scoped to root-authorized service publication and target-scoped endpoint resolution.

The scoped governance rules are:

• Names are root-seeded metadata and never caller-selected resolution authority.
• Only possession of a target's resolution scope authorizes that target.
• Publication activation requires a sealed seed entry and an exact normalized receipt for the role-derived source provenance and publication destination; a pre-existing numeric slot or unreceipted local capability is never adopted.
• Malformed, cross-plane, or unauthorized requests fail closed.
• Unexpected transfer receipts are revoked after dispatch. If revocation cannot be proven complete, named self-terminates so process teardown removes every local alias.
• A failed materialization never intentionally leaves destination authority.
• Private providers remain boot-wired and are not added to public discovery.
• Fair endpoint scans distinguish idle RETRY from BUSY, which identifies a waiting transfer-bearing caller. The latter arms one blocking receive without a service-local deadline so activation and materialization cannot be starved.

Authority boundaries

• named receives one root control endpoint with RECV|GRANT.
• named receives three target-specific resolution endpoints with RECV|GRANT.
• Activated publication slots retain exact target-specific authority; only IRQD retains GRANT, because registration transfers a handler endpoint.
• Seed, seal, and resolve accept no incoming authority. Activation retains only its single role-matched receipt.
• Callers receive only their declared target scopes with SEND|GRANT.
• No primary kernel-control endpoint, logging endpoint, or ambient lookup source is present.

Contact

Development occurs in the 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.