dynlinkd

dynlinkd is the EriX dynamic-linker service for supported native dynamic objects.

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 dynamic-linker service. Its purpose in EriX is to receive explicit dynamic-link requests, validate supported object metadata, and prepare deterministic dependency, symbol, and relocation plans.

Functionally, it exposes a no_std service binary plus host-side unit tests for the startup and dispatch contracts. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• validate the dynlinkd startup envelope and capability intake contract
• serve the Phase 5.4 typed dynamic-object resolve IPC request
• call lib-dynlink for supported ELF64 native dynamic metadata planning
• enforce bounded object, dependency graph, symbol, relocation, and recursion limits
• return deterministic success or failure classes without leaking partial plan metadata on failure

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.

Status

Implemented Phase 5.4.3 baseline plus Phase 5.4.33 dynamic startup:

• #![no_std], target-none service binary with a fixed linker base
• true dynamic executable packaging through the signed boot dynamic catalog
• service startup validation for SERVICE_ROLE_DYNLINKD
• one required receive endpoint and no primary-control endpoint
• no VFS peer grant in the first slice; callers supply inline metadata tables
• typed IPC_PHASE5_DYNLINKD_OP_RESOLVE_OBJECT dispatch
• deterministic response bodies for success, malformed, unsupported, manifest, symbol, relocation, and limit classes
• host unit tests for startup validation, request dispatch, limit rejection, unsupported feature rejection, loader filesystem dynamic metadata, and failure-response cleanup
• focused VM integration through phase5-dynlinkd and phase5-dynlinkd-dynamic-startup
• Phase 5.4.37 operator evidence documents dynlinkd as a self-hosted dynamic executable: its first dependency graph is resolved from the signed boot catalog through rootd/procd, and self-bootstrap failures are triaged with ERIX_ROOTD:DYNLINKD_DYNAMIC:* before the retained ERIX_ROOTD:READY:DYNLINKD launch proof
• CI test coverage for formatting, strict clippy, build, unit tests, and docs build, alongside Markdown linting

The current service prepares immutable plans. It does not discover filesystem dependencies, map process memory, apply relocations, create processes, or publish itself through named.

Dynamic Boot Artifact Evidence

Phase 5.4.37 documents dynlinkd as a dynamic boot artifact. The image build packages the dynamic-linker 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 after VFS readiness; its first-link graph comes from the boot catalog and cannot use dynlinkd's own service API. 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. dynlinkd receives only the documented startup endpoints, peers, and capabilities for its role.

Governance Principles

dynlinkd governance is scoped to dynamic-link service behavior shared by dependent repositories.

The scoped governance rules are:

• It must expose narrow, documented IPC rather than ambient filesystem search.
• It keeps all limits explicit and fail-closed.
• It preserves clean-room implementation boundaries and does not introduce external crate dependencies.
• Breaking IPC, startup, or authority changes require coordinated updates in lib-bootstrap, lib-capabi, lib-ipc, rootd, integration, and docs.

Service Boundaries

• dynlinkd carries only the capabilities delivered in its startup envelope.
• The Phase 5.4.33 startup path is linked from boot-catalog shared objects by rootd and procd before dynlinkd can serve its own API.
• Operator evidence must keep this self-host startup failure class distinct from bootloader kernel-link/catalog failures, kernel service-link failures, and ordinary service dynamic-link failures.
• The service receives only its local service endpoint.
• The service has no VFS, provider, process, frame, VSPACE, key, journal, or root-control authority in this slice.

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.