From 1c99bfbeffff04529f6f669601fdf835a73778da Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Fri, 2 Oct 2026 11:44:31 -0400 Subject: rename (cosmetic): green-eye -> risc-v-gsp-rm-debugger in user-facing names, docs, CLI, launcher and CI workflow; internal greeneye package/module identifiers unchanged (includes in-flight greeneye module edits present in the tree) --- docs/future-eng-ops.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'docs/future-eng-ops.md') diff --git a/docs/future-eng-ops.md b/docs/future-eng-ops.md index 0aa961a..00bffba 100644 --- a/docs/future-eng-ops.md +++ b/docs/future-eng-ops.md @@ -1,7 +1,7 @@ -# Future engineering operations: green-eye capabilities not yet earning their keep +# Future engineering operations: risc-v-gsp-rm-debugger capabilities not yet earning their keep > Companion to [`eng-ops.md`](eng-ops.md). That document records what the -> project uses now; this one records green-eye capabilities that are built but +> project uses now; this one records risc-v-gsp-rm-debugger capabilities that are built but > unused, partially used, planned or research, each tied to an impending > project need, scoped explicitly, and carrying an evaluation that can fail — > plus a kill criterion if it never pays off. Nothing here is a product @@ -9,7 +9,7 @@ > the physical-confirmation rules of > [`06-ACCURACY.md`](../debug/risc-v-gsp-rm-vm/docs/06-ACCURACY.md). -Status snapshot: 2026-10-02. Sources are the green-eye roadmap, tool docs +Status snapshot: 2026-10-02. Sources are the risc-v-gsp-rm-debugger roadmap, tool docs 16–27, the `harness/` entry points and the tool audit (doc 27). The tool tree is development-only: never shipped, never a dependency of `open-iov-vfio`, never present in a guest. RM 610 work is gated by human approval @@ -151,10 +151,10 @@ F11, F13). Each item carries exactly one evaluation criterion. | Field | Detail | |---|---| -| **Status** | `partially used`. `sim_bench.py`, the trace-overhead measurements (docs/16 §1.1a, docs/25 §6) and the product A/B methodology in [`01-performance-correctness-security.md`](05-operations/01-performance-correctness-security.md) §3 exist. There is no green-eye path that profiles a product run off-hardware or produces an automated before/after report. | +| **Status** | `partially used`. `sim_bench.py`, the trace-overhead measurements (docs/16 §1.1a, docs/25 §6) and the product A/B methodology in [`01-performance-correctness-security.md`](05-operations/01-performance-correctness-security.md) §3 exist. There is no risc-v-gsp-rm-debugger path that profiles a product run off-hardware or produces an automated before/after report. | | **Need** | Every emulation change is measured against docs/05 targets (e.g. init within 2× native) using physical cycles and a manual harness; pre-screening structural regressions off-hardware would reduce failed physical cycles. M7 timing is never claimed, so the useful signal is structural (instruction/event counts, session bytes, written pages), not wall clock. | | **Scope** | Does capture deterministic structural metrics per session and diff them before/after with an explicit fidelity label; does not make timing or wall-clock claims about silicon, does not replace the physical benchmark in docs/05. | -| **Evaluation** | Metric: fraction of perf-sensitive emulation changes that receive a green-eye before/after report before the physical benchmark. Baseline: 0. Threshold: five consecutive changes carry a report, and structural regressions ≥10% are flagged before the hardware run. Kill: if reports agree with the physical benchmark less than 50% of the time, retire them to debug annotations only. | +| **Evaluation** | Metric: fraction of perf-sensitive emulation changes that receive a risc-v-gsp-rm-debugger before/after report before the physical benchmark. Baseline: 0. Threshold: five consecutive changes carry a report, and structural regressions ≥10% are flagged before the hardware run. Kill: if reports agree with the physical benchmark less than 50% of the time, retire them to debug annotations only. | | **Gates** | H2.2 for real firmware; docs/06 M7 rule; docs/05 methodology is authoritative. | | **Effort / priority** | 2–3 engineering-weeks; **P3**. | @@ -219,9 +219,9 @@ F11, F13). Each item carries exactly one evaluation criterion. |---|---| | **Status** | `planned`. The repository has a tracked SBOM ([`SBOM.md`](../SBOM.md), CycloneDX) and the wiki GPU SBOM is superseded; there is no observation-derived inventory per firmware image that links services, symbols and dispatch tables to the SBOM and architecture docs. | | **Need** | Version bumps change firmware components and external tooling dependencies; provenance, license and vulnerability response need to know what an image contains and what changed. The architecture docs drift from the binary until a costly re-analysis rediscovers the delta. | -| **Scope** | Does derive an observation-backed component/capability inventory per image (hashes, symbols, services, dispatch tables, external dependencies) and link it to SBOM/architecture updates; does not assert legal conclusions, does not name local sources, does not auto-publish un-reviewed findings. | -| **Evaluation** | Metric: SBOM/architecture deltas per release that are observation-derived and reviewable. Baseline: manual entries. Threshold: one release where every added/removed firmware component row carries a hash plus evidence link from a green-eye session. Kill: if observation rows are rejected by SBOM review twice, drop to a provenance annex inside the session evidence. | -| **Gates** | H2.2 for real images; legal-and-licensing review ([`legal-and-licensing.md`](09-reference/legal-and-licensing.md)); local-provenance rules. | +| **Scope** | Does derive an observation-backed component/capability inventory per image (hashes, symbols, services, dispatch tables, external dependencies) and link it to SBOM/architecture updates; does not assert legal conclusions, does not name source locations, does not auto-publish un-reviewed findings. | +| **Evaluation** | Metric: SBOM/architecture deltas per release that are observation-derived and reviewable. Baseline: manual entries. Threshold: one release where every added/removed firmware component row carries a hash plus evidence link from a risc-v-gsp-rm-debugger session. Kill: if observation rows are rejected by SBOM review twice, drop to a provenance annex inside the session evidence. | +| **Gates** | H2.2 for real images; legal-and-licensing review ([`legal-and-licensing.md`](09-reference/legal-and-licensing.md)); provenance rules. | | **Effort / priority** | 2–3 engineering-weeks; **P3**. | ## 4. Pruning and retirement @@ -245,14 +245,14 @@ at the first review, delete it rather than documenting API symmetry. | Trigger | Who | What is re-checked | |---|---|---| -| H2.2 exit | green-eye maintainer + eng-ops owner | F5, F6, F7, F8, F14, F15 gates open; statuses move to `partially used`/`planned` execution | -| Each GSP/driver release | green-eye maintainer | F1/F2/F3 chain cost, F14 findings, F15 SBOM deltas; kill criteria evaluated | +| H2.2 exit | risc-v-gsp-rm-debugger maintainer + eng-ops owner | F5, F6, F7, F8, F14, F15 gates open; statuses move to `partially used`/`planned` execution | +| Each GSP/driver release | risc-v-gsp-rm-debugger maintainer | F1/F2/F3 chain cost, F14 findings, F15 SBOM deltas; kill criteria evaluated | | RM 610 approval request | project lead + maintainer | F1 evidence (C4/C5), bundles for C8; no 610 input before approval | | Quarterly | eng-ops owner | Re-run or explicitly defer every evaluation; prune/demote/keep decisions recorded in §4 | | New funded use case | project lead | Admit a new item with the same six fields; research items become `planned` only with funding | The doc is reviewed against the tool audit ([`27-TOOL-AUDIT.md`](../debug/risc-v-gsp-rm-vm/docs/27-TOOL-AUDIT.md)) -and the roadmap ([`GREEN-EYE-ROADMAP.md`](../debug/risc-v-gsp-rm-vm/GREEN-EYE-ROADMAP.md)) +and the roadmap ([`RISC-V-GSP-RM-DEBUGGER-ROADMAP.md`](../debug/risc-v-gsp-rm-vm/RISC-V-GSP-RM-DEBUGGER-ROADMAP.md)) so the "what we use now / not yet" split stays true.