Conversation
…ive MMK.EXE (PATH 1 measure)
The QEMU drive tests (test_syssvc_mmk_build / test_syssvc_mmk_drive) drove the
STATIC mmk_native CMake target. This swaps their shared subject
(/vms/SYS0/SYSCOMMON/SYSEXE/MMK.EXE) to the OVMX-native, IMGACT-ACTIVATED MMK.EXE
(mk_mmk.sh: 19 objects, LINK.EXE --executable --use {DECC$SHR + the six OVMX
shareables}, PT_INTERP=IMGACT.EXE) — the convergence "OVMX builds OVMX with the
real activated image, the VMS way", exercising the real spawn+mailbox+WRTATTN-AST
exec-drive of an activated image over a real /dev/vms.
Staging-only (vms-c09f boundary — NO link.c/imgact.c edits):
- new src/vmslink/mk_mmk_native_staged.sh centralises the recipe (so the Docker
base build and inject_and_run.sh per-defect rebuild cannot drift): it reuses the
proven, arch-adaptive build_producer_graph (lib_build_graph.sh; x86_64 supported
via -mtls-dialect=gnu2, vms-cb5f) + mk_mmk.sh. `full` mode builds the whole
7-producer graph + MMK.EXE; `mmk-only` relinks just MMK.EXE reusing staged
shareables.
- Dockerfile: full-mode build stages all 7 shareables into SYS$LIBRARY + the
activated MMK.EXE into SYS$SYSTEM (the activated MMK --uses all 7, so all 7 must
be where IMGACT resolves them). Overwrites the static MMK + re-emits identical
IMGACT/DECC$SHR; LINK.EXE untouched.
- inject_and_run.sh: per-defect rebuild is mmk-ONLY (the negctl shard runs ~7
defects under 50m; only ovmx_mmk_sp.c in MMK is ever mutated, shareables never
change per-defect, so a full graph rebuild each time would risk the timeout).
Removed the static-MMK re-stage cp that would clobber the activated image.
- Both tests' "bare static image" comments updated to the activated reality.
MEASURE (conductor PATH 1): the 7 shareables BUILD on x86_64 (build_producer_graph
is arch-adaptive); the open fact this proves is whether the 19-object/7-shareable
ACTIVATED MMK.EXE ACTIVATES on x86_64 IMGACT (vs the proven 1-TU/1-shareable
OVMXRT). GREEN = vms-c09f done. ARCH-FAIL = a discovered x86_64 multi-shareable
activation gap in LINK/IMGACT, filed as a separate operator-gated item; vms-c09f
waits honestly (do NOT force it).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…k_mmk.sh (x86_64 build fix) The first x86_64 measure (run 34883074634) failed at Docker image-build time: build_producer_graph set -mtls-dialect=gnu2 for the 7 shareables, but the mk_mmk.sh call inherited NO CFLAGS, so mk_mmk.sh used its aarch64-only default (-mno-outline-atomics) to compile the 19 MMK objects -> invalid on x86_64. Compute ARCHFLAG (aarch64: -mno-outline-atomics; x86_64: -mtls-dialect=gnu2, matching lib_build_graph.sh) and pass CFLAGS to mk_mmk.sh in both full + mmk-only modes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
baron-3dl
force-pushed
the
work/vms-c09f-mmk-activate
branch
from
September 14, 2026 18:59
c5d0cf2 to
64c727b
Compare
…ty_negctl.sh The x86_64 re-measure built+booted but pristine mmk_build+mmk_drive went TOTALLY red (base_reds = every mmk assertion), and the CI log shows only the harness summary -- not the guest per-assertion console -- so the FIRST real failure (activation gap vs build/CLI/staging error) can't be classified from the log. On positive-control failure, dump each pristine-red suite's raw guest console section from $OUTFILE (awk-sliced by the '=== SUITE name rc=' delimiters, tail-capped) so the failure mode is visible in the log. Diagnostic only; no behavior change to the gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…CP (shared helper)
The diagnostic (run 34886255430) pinned the pristine-red mmk_build/mmk_drive to
%IMGACT-F-IMGNOTFND on /vms/SYS0/SYSCOMMON/SYSEXE/MMK.EXE: the now-ACTIVATED
MMK.EXE subject was not on the system volume IMGACT resolves the main image off.
Reading imgact.c settles the fix. The MAIN image is opened off OVMX_SYSDEVICE
through the ACP (imgsrc_open -> imgact_acp_open, g_acp_sysdevice) with NO /vms
fallback -- a missing main image fails-honest die_imgnotfnd, and that is CORRECT
(Rule 9 / INV-6). The IMGACT_FALLBACK_SYSLIB /vms fallback is SHAREABLE-only and
always-on; extending it to the main image would either mask a real production
IMGNOTFND (always-on) or not fire here at all (the volume IS mounted). So there
is no faithful+effective imgact.c change: the subject must LIVE on the volume,
exactly as a real VMS image lives on the system disk (and as this suite already
writes the PRODUCED OVMXRT.EXE onto VDA300:).
Runtime staging (not pre-mastering into mkimage_ods2_sysvol) is REQUIRED, not
just convenient: the negctl per-defect rebuild mutates MMK.EXE
(mmk-drive-command-not-sent, compiled into it), so the harness must write the
CURRENT MMK.EXE onto the volume at test time or the defect never reaches IMGACT
-- pre-mastering the pristine image would be a fake gate (INV-6).
- NEW tests/qemu/sysvol_stage.h: lifts mmk_build's VDA300: mount + resolve
[SYS0.SYSCOMMON.SYSEXE] + write-over-ACP + OVMX_SYSDEVICE into ONE shared
unit (sysvol_prepare / sysvol_write_image / sysvol_stage_host_image /
sysvol_stage_subject). Header-only static helpers (each suite compiles
standalone), unused-safe.
- test_syssvc_mmk_build.c: drop the now-duplicate globals + resolve_dir_fid +
sysvol_prepare + write_produced_image, use the shared helper, and stage the
activated MMK.EXE subject onto the volume before the drives (basename(mmk)).
- test_syssvc_mmk_drive.c: had none of this machinery -- now mounts VDA300:,
stages the subject, and points IMGACT at it (child inherits OVMX_SYSDEVICE).
MMK's execfn is the /vms SYSEXE path directly (not a /run/ovmx-boot staged
path), so imgsrc_map_staged passes it through and IMGACT reads it off the volume
-- MMK needs ONLY the on-volume copy, no boot-stage. Both TUs compile clean
(musl-gcc -fsyntax-only): only the pre-existing RMS FAB -Woverflow warnings.
Boundary held: staging only, no link.c/imgact.c edits.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Swaps
test_syssvc_mmk_build+test_syssvc_mmk_drive's shared subject from the STATICmmk_nativeto the OVMX-native, IMGACT-activated MMK.EXE (mk_mmk.sh: 19 objects, LINK.EXE--executable --use {DECC$SHR + 6 OVMX shareables}, PT_INTERP=IMGACT.EXE). The self-hosting convergence: OVMX builds OVMX with the real activated image, driving the actual spawn+mailbox+WRTATTN-AST exec-drive over a real /dev/vms.Staging-only (boundary: no link.c/imgact.c)
src/vmslink/mk_mmk_native_staged.shcentralises the recipe (Dockerfile + inject_and_run can't drift): reuses arch-adaptivebuild_producer_graph(x86_64 via-mtls-dialect=gnu2, vms-cb5f) + mk_mmk.sh.full= whole 7-producer graph + MMK;mmk-only= relink MMK reusing staged shareables.Measure (PATH 1)
The 7 shareables build on x86_64. The open fact: whether the 19-object/7-shareable activated MMK activates on x86_64 IMGACT (vs the proven 1-TU OVMXRT). GREEN = done. ARCH-FAIL = discovered x86_64 multi-shareable activation gap → separate operator-gated LINK/IMGACT item, vms-c09f waits (not forced).
🤖 Generated with Claude Code