diff options
Diffstat (limited to 'debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md')
| -rw-r--r-- | debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md | 19 |
1 files changed, 13 insertions, 6 deletions
diff --git a/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md b/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md index 30f4720..ad8a5e7 100644 --- a/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md +++ b/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md @@ -71,7 +71,7 @@ tools/cudatool.py delta <old>/run/libcuda.so.<old> <new>/run/libcuda.so.<new> | Step | Existing project tooling | green-eye addition | |---|---|---| | Export/interface diff | `tools/cudatool.py delta` | — | -| Function matching / name-transfer measurement | `tools/cudatool.py fdematch --names <names.tsv>` | — | +| Function matching / name-transfer measurement | `tools/cudatool.py fdematch <old-lib> <new-lib> --names <names.tsv>` | — | | Corpus-level diff (added/removed/resized functions) | `tools/diff_corpus.py <old_index> <new_index>` | — | | Name transfer + corpus annotation | `ApplyNameMap.java` (`--dry-run` first), `tools/annotate_corpus.py` | `./greeneye.sh symbols export` builds a runtime-address symbol DB from the same index/names | | Driver-API smoke | `tools/test/cuda_drv_test.c` compiled as `/tmp/cdt` (prints `ALL OK`) | `./greeneye.sh symbols resolve --db ... <addr>` spot-checks transferred addresses per call path | @@ -241,9 +241,11 @@ The project's support ladder is `docs/06-portability/hardware-software-matrix.md 1. Run `harness/portability_matrix.py` across the reference and candidate device firmware with the same scenario options (docs/18 §1); keep `<out>/portability-report.json`, per-pair compare reports and sessions. -2. The planned version-diff/CI pipeline (docs/21-CI-RELEASE-PIPELINE.md, - planned) is where those reports become release-gated artifacts; until it - exists, attach them to the matrix process manually. +2. The version-diff/CI pipeline + ([`docs/21`](21-CI-RELEASE-PIPELINE.md)) packages those reports into + release-gated artifacts; the porting scaffolds + ([`docs/28`](28-PORTING-AUTOMATION.md)) wrap it per version as unadmitted + pilots (evaluation in future-eng-ops F2/F3). 3. Update the device profile (documentation today; `config/hardware/*.yaml` is not read by code — do not claim configuration-driven portability). 4. Validate on the physical device with the supervised harness before claiming @@ -345,9 +347,14 @@ Architecture (P3): | Differential execution and reimplementation loop | H4.5 | every port lands with A/B sessions and the M1–M6 table | reference-capture pipeline | | Adjacent-controller work for GB10-class bring-up | H5 | PMU/SEC2/ACR/SOE models, cross-controller sessions | H2.2 | | Multi-target orchestration | R6 / docs/18 | one report across firmware/device targets | v0.1 stable | -| Version diff and release gating | planned (docs/21) | CI pipeline that gates a port on the evidence bundle | pipeline implemented | -| Control discovery | planned (docs/19) | systematic control/class inventory across versions | document exists | +| Version diff and release gating | implemented (docs/21) | CI pipeline that gates a port on the evidence bundle | pipeline implemented | +| Control discovery | implemented (docs/19) | systematic control/class inventory across versions | document exists | Program-level success criterion served here: a new GSP version (or device) can be triaged — inventory diff + behaviour diff + metric table — in **hours**, with recorded evidence. + +<!-- change (2026-10-02): fix the fdematch invocation (it needs two libraries), +and replace "planned docs/19/21" with their implemented status plus the docs/28 +scaffolds; scope: §2.2, §3.5, §6 only; benefit: commands run as written and +status tables match the tree. --> |