extop

extop is the native EriX process monitor. It is a dynamically linked, freestanding executable installed on the ext4 runtime partition and launched through launchd, loaderd, dynlinkd, and procd after the partition is mounted.

Purpose of This Repository

The monitor renders a top-like terminal view containing:

• every processor reported by the explicit topology snapshot, with utilization derived from monotonic busy/total counter deltas between successful sweeps
• allocator-domain used and total bytes, with percentage defined as allocated / usable
• the live launch jobs visible through the caller's receiver-selected session, including process state and accumulated user-plus-system CPU nanoseconds
• whether an independently delegated exact job-control handle is available for a displayed row

Numeric session, job, process, generation, cursor, and slot values are data. They never create or select authority.

Clean-Room Policy

• Do not copy external source code or documentation.
• Do not add external Rust crates.
• Keep implementation, protocol fixtures, and test inputs independently reviewable within EriX.

License

Licensed under the ISC License.

Runtime Authority

The complete child CSpace is validated before I/O. Its only fixed external capabilities are exact send-only endpoints for:

• TTY session lifecycle
• standard input, output, and error
• the current job's launchd accounting route, upgraded to session inspection only by the exact command-manifest/TTY/script-policy intersection

Optional process control is represented only by exact send-only job-control handles explicitly delegated for this invocation. Each --control=JOB:GEN argument is a non-authoritative reconciliation claim: extop enables that handle only after an identity read through the handle itself reports the same job and generation, and later requires the selected process row's session to match.

Extop admits no cwd, resolver, public launch, loaderd, dynlinkd, procd, memd, kernel-control, block, device, key, global VFS, endpoint-factory, or service- discovery authority. If the session snapshot is unavailable, there is no privileged fallback.

Interaction

• --samples=N: render exactly N refreshes and exit successfully; this authority-free bounded mode is intended for capture and integration checks
• q: exit
• r: request an immediate refresh
• Up/Down or k/j: move selection
• i: interrupt through the selected row's explicit handle
• s: request stop through the selected row's explicit handle
• c: request continue through the selected row's explicit handle
• t: terminate through the selected row's explicit handle

Resize and mode events cause dimensions to be read again from the exact TTY lifecycle route. Hangup exits cleanly; terminal interrupt exits with status 130. Disappearing jobs are removed only after a complete cursor enumeration, and selection is repaired by exact job generation.

Capacity and Backpressure

Processor, process, and optional-control arrays come from a package-patched, page-aligned writable workspace. The runtime imposes no hidden record ceiling; volatile reads preserve the patched words against build-time constant folding, and insufficient deployment capacity is an explicit startup or refresh failure. Rendering assembles each clipped line in bounded stack storage and submits that line through one exact-stdout write, then follows receiver progress without truncating retained state. This keeps concurrent kernel diagnostics from splitting the dashboard's line-level serial evidence at scheduler boundaries.

Packaging

manifests/extop-v1.txt is the repository-owned catalog for /bin/extop. Its manifest ceiling contains a non-interactive exact session inspection row and a separate interactive process-control ceiling. The executable must remain absent from boot.img.

The release ELF carries an ERIXTOPCAPLAY001 record. Image construction patches its workspace byte length and processor/process/control capacities before the runtime graph, executable content, and command-entry manifest are hashed. Runtime reads those authenticated post-link words through volatile accesses before validating or using the workspace.

The focused positive VM scenario boots two processors and runs extop --samples=2 through ext4 exsh, requiring two ordered dashboards, both processor rows, nonzero allocator use, and a live session process row. Its bootstrap session carries only inspection authority. The paired negative keeps the session deny-all, supplies a forged numeric job claim, requires launch denial, and forbids dashboard output. Both scenarios live in the integration repository and run during the current regression-validation pass.

Target fail-stop statuses distinguish panic (0xE0), raw startup entry rejection (0xE1), the reserved former aggregate runtime code (0xE2), authenticated startup image, command, argument, description, control-slot, and CSpace rejection (0xE3–0xE8), and packaged capacity, control-capacity, or workspace rejection (0xE9–0xEB). Live failures use 0xEC–0xF6 for control initialization, stream initialization, terminal state, metrics, processes, rendering, sample counting, events, input, and control. Metrics failures are further separated as transport, capacity, sample, or cross-processor mismatch at 0xF7 and 0xF9–0xFB. A rejected metrics reply mirrors canonical IPC results one through eight as 0xD1–0xD8 and uses 0xDF for an unknown result. The former aggregate rejection result 0xF8 remains reserved. These values are diagnostic process results only; they grant no authority and do not permit recovery through a broader route.

Development Model

cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-targets --all-features
cargo doc --no-deps --all-features
cargo check --lib --bin extop --target x86_64-unknown-none --all-features
RUSTFLAGS='-D warnings -C link-arg=-Tlinker.ld' \
  cargo build --release --bin extop --target x86_64-unknown-none \
  --features extop-runtime

Git dependencies use full 40-character commit rev pins. Integration source revisions and CI caches preserve those identities without branch-head or synthetic-commit substitution. No third-party crates are used.

Governance Principles

• Runtime authority must remain limited to authenticated session inspection and independently delegated exact job-control handles.
• Numeric process and job claims remain descriptive and cannot select a target.
• Protocol or authority changes update direct consumers, focused tests, and system documentation together.
• Non-obvious authority or lifecycle changes require documented rationale.

Contact

Development occurs in the EriX organization. Maintainers can be reached at admin@erikinkinen.fi.