- Rust 99.1%
- Linker Script 0.9%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Erik Inkinen
16bcbac4c9
Merge the selected feature/native-cli history with an explicit two-parent commit so main retains the development lineage and the validated source snapshot. The resulting tree is identical to the selected feature commit; no dependency pins or runtime behavior are changed by this merge. Previous main: |
||
| .github | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .markdownlint-cli2.yaml | ||
| ARCHITECTURE.md | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| linker.ld | ||
| README.md | ||
| ROADMAP.md | ||
| rustfmt.toml | ||
| SECURITY.md | ||
hotplugd
hotplugd is the hardware hotplug mediation daemon 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 hotplug service daemon. Its purpose in EriX is to provide the hotplug 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 hotplug service runtime and state model
- validate startup authority before accepting IPC requests
- handle length-checked 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.
Build
cargo build --all-targets --all-features
Test
cargo test --all-targets --all-features
cargo clippy --all-targets --all-features -- -D warnings
Build and Test Modes
This repository supports explicit runtime and integration feature gates.
hotplugd-runtimeselects production bootstrap/runtime behavior.hotplugd-runtime-hotplugadds live hotplug-event processing.hotplugd-integration-smokeenables synthetic end-to-end validation paths.hotplugd-integration-force-failremains test-only and MUST NOT be enabled for runtime appliance builds.hotplugd-integration-hotplugselects the live hotplug path for the focused integration appliance.
The manifest contains no legacy runtime-feature aliases.
Validation Note
The host/test QUERY_CAP fallback remains cfg-scoped so runtime/release builds
stay warning-free.
Dynamic Boot Artifact Evidence
The runtime image contract documents hotplugd as a dynamic boot artifact.
The image build
packages the hotplug service daemon 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 hotplug endpoint and startup 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. hotplugd receives
only the documented startup endpoints, peers, and capabilities for its role.
Governance Principles
hotplugd governance is scoped to hotplug event coordination.
The scoped governance rules are:
- It processes only explicit hotplug events from authorized sources.
- It coordinates with device-management policy without owning driver launch authority.
- It uses the caller-selected event count as the exact per-call work budget, including a valid empty budget.
- It rejects malformed or unauthorized hotplug notifications.
- It retains accepted peer calls and service replies until authoritative completion, without service-local time ceilings.
Authority Boundaries
hotplugdoperates only through startup-assigned service capabilities.- New authority must be represented in bootstrap/capability validation and integration tests before use.
- Runtime, startup, kernel-control, and
devicedreply envelopes declare no capability transfer. Complete unexpected receipts are retired before the message is rejected; malformed receipt state or failed retirement terminates the process so kernel teardown revokes every remaining alias. - The full transport-capacity server buffer accepts protocol envelopes without
a private ceiling. The retained
devicedclient buffer is sized exactly for the sole report request/response family.
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.