irqd

irqd is the interrupt routing 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 irq service daemon. Its purpose in EriX is to provide the irq 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 irq 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.

Status

• IRQ routing path is implemented for IPC_INTERRUPT_LINE_LAPIC_TIMER.
• Root orchestration integration is implemented (named -> timed -> logd -> crashd -> irqd -> ...).
• Runtime interrupt and ACK control now use only the startup-assigned primary control slot.
• irqd now receives a dedicated primary control slot at SLOT_KERNEL_IRQ_ENDPOINT (2144) instead of the broad root endpoint.
• Startup ready-state validates actual local slot type/rights with bare-metal QUERY_LOCAL_CAP and host/test QUERY_CAP fallback.
• The linker now keeps the dedicated .stack_reserve inside the loaded image so early startup validation does not fault on stripped reserve pages.
• Positive, SMP, and missing-service negative VM scenarios are implemented and passing.

Runtime model

irqd lifecycle:

1. Startup envelope validation and ready reply.
2. Self-registration with named.
3. Root-seeded handler tuple intake (SEED_HANDLER) and SEAL.
4. Handler activation by exact tuple match (REGISTER_HANDLER).
5. Interrupt wait/dispatch loop:
   • wait kernel interrupt event,
   • send typed notify payload to registered handler endpoint,
   • require explicit ACK before the next delivery for the line.

Mask policy is controlled via SET_MASK, mapped to kernel interrupt-line configuration.

Build and test

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

Dependencies

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

No third-party crates are used.

Validation Note

The host/test QUERY_CAP fallback remains cfg-scoped so runtime/release builds stay warning-free. The runtime path now uses only the kind-aware query helper so release image builds do not retain dead local-cap wrappers.

Governance Principles

irqd governance is scoped to interrupt registration and event distribution.

The scoped governance rules are:

• It registers interrupt consumers only through explicit authority.
• It preserves bounded delivery and validates interrupt ownership before dispatch.
• It keeps hardware interrupt routing policy outside individual drivers.
• It does not grant device or process-management authority to consumers.

Authority Boundaries

• irqd operates only through startup-assigned service capabilities.
• 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.