vms-76c3: wire F$GETSYI("ARCH_NAME") in the DCL lexical + running per-arch battery coverage - #868
Merged
Merged
Conversation
…-arch battery coverage
Closes out the F$GETSYI coverage. F$GETSYI("ARCH_NAME") was UNWIRED in the DCL
lexical (dcl_lexical.c handled only VERSION/HW_NAME/...), so it fell through to
"0" -- while the $GETSYI SERVICE (sys_misc.c SYI$_ARCH_NAME) already returned the
real arch token via ovmx_hw_arch(). vms-10e made ovmx_hw_arch() report VAX/Alpha
(was UNKNOWN), but only the host unit test covered it; the arch token had no
running per-arch proof.
- dcl_lexical.c: F$GETSYI("ARCH_NAME") -> ovmx_hw_arch() (the SAME SSOT the
service uses, so the two surfaces never disagree). NOT space-padded (byte-
confirmed on the live oracle: "Alpha" exact) -- a plain copy, unlike VERSION's
fixed 8-char field.
- shared battery: a bracketed WRITE F$GETSYI("ARCH_NAME") assertion (all three
gates) against caller-provided EXPECTED_ARCH_NAME, plus a '[0]' bug guard for
the old unwired fall-through. New EXPECTED_ARCH_NAME contract var.
- gate drivers set their build arch: VAX -> "VAX", Alpha -> "Alpha", x86_64 ->
"X86_64" / aarch64 -> "AARCH64".
Cascade: API-compat additive (new item code, no caller breaks); test = the new
runtime battery assertion (arch token now proven per-arch on a real boot, not
just the host unit test); no doc.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QSU1Hfy7UzVE6msx3hecWM
baron-3dl
added a commit
that referenced
this pull request
Aug 28, 2026
…y.sh) vms-76c3/#868 added tests/qemu/lib/dcl_acceptance_battery.sh (used by the DCL ACCEPTANCE harness, not run_tests.sh), but tests/qemu/Dockerfile's guard still demanded lib/ hold exactly ONE file -- so the kernel-executive image build (kernel-executive-shard, ci.yml) failed FATAL before booting a single suite. Replace the bare count with an allow-list: harness_verdict.sh (copied in) and dcl_acceptance_battery.sh (intentionally not in this image); any OTHER file still trips the guard. Not a weakening -- a new unaccounted helper still fails the build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
baron-3dl
added a commit
that referenced
this pull request
Aug 28, 2026
…ST + $DEQ) (#873) * vms-904c: DLM rung 3 — cross-node contention (block-then-grant + BLKAST + $DEQ) Lift the H4 ENQ scope-fence for real on the mastering node. An incompatible cross-node $ENQ now QUEUES on the master's real waiting queue (VMS_DLM_STS_QUEUED — not SS$_NORMAL, not SS$_NOTQUEUED), the master fires the blocking-AST decision naming the remote holder (blocking_csid), and a real cross-node $DEQ (vms_lock_dlm_xnode_deq, authorized by CSID) releases and grants the blocked request. Higher rungs (directory/remaster/LVB/deadlock) stay honestly SS$_UNSUPPORTED or omitted (INV-6 — no fake grant OR block). - kernel-core/vms_lock.c: vms_enq_core -> vms_enq_core_ex(xn); cross-node mode skips proc-keyed deadlock detection (distributed = rung 7) and queues instead of declining; new vms_lock_dlm_xnode_deq; dispatch ENQ/DEQ rewritten. - vms_ioctl.h: vms_dlm_xnode_args gains queued/blocking_csid/blocking_master_lkid outputs; VMS_DLM_STS_QUEUED sentinel. - vms_kif dlm_xnode: return the contention outputs. - test_syssvc_dlm_xnode.c: assert grant -> block (granted NL, BLKAST directive = holder) -> $DEQ -> grant (NL->EX flip) on real /dev/vms (x86_64 + Alpha LP64). - cluster-dlm.yaml: cross-node-lock -> partial (contention landed); split out the still-absent remaster/LVB/deadlock rungs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * vms-904c: mirror the extended vms_dlm_xnode_args into the NetBSD kernel-core header src/kernel-netbsd/vms_lock_nb.h carries its own copy of struct vms_dlm_xnode_args (kernel-core is shared Linux vms.ko + NetBSD vms.kmod) with a size static-assert. Add queued/blocking_csid/blocking_master_lkid + the VMS_DLM_STS_QUEUED sentinel and bump the assert 84 -> 92 to match src/kernel/ vms_ioctl.h, else the NetBSD/VAX module leg reds on the ABI-freeze assert. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * tests/qemu: fix lib_check guard broken by #868 (dcl_acceptance_battery.sh) vms-76c3/#868 added tests/qemu/lib/dcl_acceptance_battery.sh (used by the DCL ACCEPTANCE harness, not run_tests.sh), but tests/qemu/Dockerfile's guard still demanded lib/ hold exactly ONE file -- so the kernel-executive image build (kernel-executive-shard, ci.yml) failed FATAL before booting a single suite. Replace the bare count with an allow-list: harness_verdict.sh (copied in) and dcl_acceptance_battery.sh (intentionally not in this image); any OTHER file still trips the guard. Not a weakening -- a new unaccounted helper still fails the build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * vms-904c: regenerate compatibility-surface.md from cluster-dlm.yaml (INV-LEDGER) Derived surface regen after the cluster-dlm rung-3 yaml edit (partial +1, real +1, 406 items). tools/compat/render_compat.py; md is generated, yaml is source. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- 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.
Closes out the F$GETSYI coverage — the arch token now has a running per-arch proof on a real boot, not just the host unit test.
The gap
F$GETSYI("ARCH_NAME")was unwired in the DCL lexical (dcl_lexical.chandled only VERSION/HW_NAME/…), so it fell through to"0"— even though vms-10e madeovmx_hw_arch()report VAX/Alpha (was "UNKNOWN") and the$GETSYIservice (sys_misc.cSYI$_ARCH_NAME) already returned it. So a user typingWRITE SYS$OUTPUT F$GETSYI("ARCH_NAME")in DCL got0.Change
dcl_lexical.c:F$GETSYI("ARCH_NAME")→ovmx_hw_arch()(the same SSOT the service uses, so the two surfaces never disagree). NOT space-padded — byte-confirmed on the live oracle ("Alpha" exact), a plain copy unlike VERSION's fixed 8-char field.WRITE F$GETSYI("ARCH_NAME")assertion (all three gates) against caller-providedEXPECTED_ARCH_NAME, plus a[0]bug guard for the old unwired fall-through.Cascade
ovmx_hw_arch()=="X86_64".Validation
VAX rail run in progress (SHA bd75003,
FORCE_SYSVOL_BUILD=1rebuilds DCL.EXE) — asserts[VAX]. Alpha[Alpha]/ x86[X86_64]ride their gates. Green-by-SHA report to follow.🤖 Generated with Claude Code