Skip to content

vms-3320: extend the alpha CRTL->RMS veneer beyond stdio (open/creat/unlink/remove/rename/opendir/readdir/closedir over RMS) - #1085

Open
baron-3dl wants to merge 2 commits into
mainfrom
work/vms-3320-crtl-rms-fileops
Open

vms-3320: extend the alpha CRTL->RMS veneer beyond stdio (open/creat/unlink/remove/rename/opendir/readdir/closedir over RMS)#1085
baron-3dl wants to merge 2 commits into
mainfrom
work/vms-3320-crtl-rms-fileops

Conversation

@baron-3dl

@baron-3dl baron-3dl commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Extends the alpha CRTL→RMS veneer past the stdio family so the alpha-dec-vms GCC port's decc$ file-ops reach real Files-11 ODS-2 over the executive ACP instead of musl-POSIX ramfs. Blocks vms-fd1 (the port can't compile real C without temp-file/cleanup/dir-enum/atomic-rename reaching RMS).

8 ops bound, fail-honest (INV-6 / Rule 9), no POSIX fallback on the executive-present path:

  • open/creat → sys$create/$open + an fd table based at 0x40000000 (veneer fds never collide with musl fds)
  • unlink/remove → sys$erase (IO$_DELETE)
  • rename → a new thin sys$rename RMS service driving the existing executive primitive IO$_MODIFY!IO$M_MOVE (vms-de7) — one atomic directory-entry re-link that keeps the File ID, not erase+create
  • opendir/readdir/closedir → sys$parse + sys$search + rms_search_fid

DECC$SHR wiring: the 8 decc$ names are substituted to their ovmx_crtl_* aliases in-place at each name's sorted sv# slot (never tail-appended — the vms-b14 sv#-skew trap; IMGACT binds by index), with a 12-name presence guard.

Proof — teeth green:

  • x86_64 /dev/vms (real executive/ODS-2/ACP): 40/40, independent ACP reader per op — creat→File ID +;1; unlink→GONE; rename→same File ID (atomic re-link, not copy); readdir→File IDs match an independent sys$search.
  • Alpha static: all 8 substituted in DECC$SHR; sys$rename sv#95; port image STRICT-links 0-deferred/0-undef.
  • New alpha gate crtl-rms-fileop-gate boots crtl_rms3_test.c on the real executive + runs the independent DIRECTORY reader.

Known: the alpha veneer image inherits the pre-existing vms-c5d (__malloc_donate/__libc_free) post-commit crash (veneer-build-only, not this change — x86_64 is clean); crtl_rms3 commits all effects before its single free(), so the independent-reader proof banks like the vms-f49 veneer gate. vms-c5d tracked separately; root linker fix vms-f59.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ

@baron-3dl
baron-3dl force-pushed the work/vms-3320-crtl-rms-fileops branch 2 times, most recently from 552da22 to 6b2c725 Compare September 9, 2026 14:47
@baron-3dl @claude
vms-3320: extend the alpha CRTL->RMS veneer beyond stdio — open/creat…
ae2e785 
…/unlink/remove/rename/opendir/readdir/closedir over RMS

The crtl_rms_stdio.c veneer covered only the stdio family (fopen/fwrite/
fread/fclose); the alpha-dec-vms GCC port additionally references decc$
file-ops that were still musl-POSIX (Linux-Alpha ramfs, not RMS/ACP):
open/creat (temp-file minting), unlink/remove (cleanup), rename (atomic
output finalization), opendir/readdir/closedir (dir enumeration). Blocks
vms-fd1 (the port can't compile real C without these reaching RMS).

Binds all 8 to the already-proven RMS engine over the executive ACP,
fail-honest (INV-6 / Rule 9), no POSIX fallback on the executive-present
path:
- open/creat: sys$create/$open + an fd table based at 0x40000000 (veneer
  fds never collide with musl POSIX fds).
- unlink/remove: sys$erase (IO$_DELETE).
- rename: a new thin sys$rename RMS service (rms_core.c) driving the
  EXISTING executive primitive IO$_MODIFY!IO$M_MOVE (vms-de7) — one atomic
  directory-entry re-link that KEEPS the File ID. NOT erase+create (which
  would be non-atomic and mint a new FID). The faithful decc$rename.
- opendir/readdir/closedir: sys$parse + sys$search + rms_search_fid.
The executive-absent host/netbsd defer is the SAME rms_acp_absent() flip
sys$erase/$open/$create already take (vms-5f0) — no new host-FS surface.

DECC$SHR wiring (mk_decc_shr.sh): the 8 decc$ names are substituted to
their ovmx_crtl_* veneer aliases IN-PLACE at each name's existing sorted
sv# slot — never tail-appended (IMGACT binds by sv# index; the vms-b14
sv#-skew trap). A 12-name presence guard + a >=12 universal floor fail the
build on any drift.

Proof — teeth green:
- x86_64 /dev/vms (real executive, real ODS-2, real ACP): 40/40 assertions,
  an INDEPENDENT ACP reader for every op (test_syssvc_crtl_rms_veneer.c):
  creat/open -> genuine File ID + version ;1; unlink/remove -> GONE;
  rename -> OLD gone, NEW present with the SAME File ID (atomic re-link,
  not copy); opendir/readdir -> enumerated entries' File IDs match an
  independent sys$search.
- Alpha static: all 8 decc$ names substituted in-place in DECC$SHR;
  sys$rename is a real LIBVMSRMS$SHR universal (sv#95); the port image
  STRICT-links binding all 8 by sv# index, 0-deferred / 0-undef.
- New alpha gate crtl-rms-fileop-gate boots crtl_rms3_test.c on the real
  executive + runs the independent DIRECTORY reader.

Known: the alpha veneer image inherits the pre-existing vms-c5d
(__malloc_donate/__libc_free) post-commit crash (veneer-build-only, not
this change — x86_64 is clean); the fileop program commits all effects
before its single free(), so the independent-reader proof banks like the
vms-f49 veneer gate. vms-c5d tracked separately (blocks a fully-clean
alpha exit); root linker fix vms-f59.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJZf62TMXxvy6fXzFQYfLQ
@baron-3dl
baron-3dl force-pushed the work/vms-3320-crtl-rms-fileops branch from 6b2c725 to ae2e785 Compare September 9, 2026 16:31
@baron-3dl baron-3dl mentioned this pull request Sep 10, 2026
Closed
baron-3dl added a commit that referenced this pull request Sep 10, 2026
@baron-3dl @claude
vms-126: test_syssvc_crtl_rms_bigwrite dismounts VDA0: — fix cross-su…
30a2e79 
…ite mount-state leak (shard-3/6 red)

The bigwrite suite $MOUNTed VDA0: executive-global (idempotent) and never
$DISMOUNTed it. It runs in the SHARED Kernel-Executive QEMU guest boot, and by
md5(suite_name)%6 lands on shard 3/6 alongside test_syssvc_startup_service,
running before it. corpus_seed_lnm seeds SYS$SYSDEVICE -> VDA0:, so with VDA0:
left mounted, startup_service's RUN/DETACHED "/bin/sh" resolves through the ACP
(dcl_resolve_activatable_acp -> rms_file_attr): the device is mounted but
busybox /bin/sh is in the initramfs, not on ODS-2 -> SS$_NOSUCHFILE -> RMS$_FNF
-> acp_usable=1 -> correct INV-6 %DCL-E-IVIMAGE (host fallback forbidden) -> 13
RUN/$CREPRC fails. Without bigwrite (main / same-base #1085), every VDA0:-mounting
suite dismounts, VDA0: is unmounted when startup_service runs -> RMS$_ACC -> host
fallback finds busybox -> 50/0 green.

Nothing is exhausted and the file cleanup was already correct (BIGWR.DAT erased);
the leaked state is the VOLUME MOUNT. Fix: $DISMOUNT VDA0: in the done: cleanup,
mirroring test_syssvc_acp_mount/_channel — leave no shared mount state behind.
The chunking + File-ID coverage is unchanged.

(Follow-ons, not #1122 blockers: vms-9af6 — the KE shard harness should reset
executive mount state between suites so one suite can't leak into a co-tenant;
and the honest-error angle is INV-6-correct here, not a mislabel.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mZSxmiHPcUBuMNiVT5jXw
baron-3dl added a commit that referenced this pull request Sep 10, 2026
@baron-3dl @claude
vms-126: complete the CRTL→RMS veneer for the GCC driver — chunked >6…
6579602 
…4KiB writes + delete-on-close temps (#1122)

* vms-126: complete the CRTL->RMS veneer for the GCC driver — chunked >64KiB writes

The RMS engine + ACP path a compiler driver needs are already ENGINE PROVEN. The
gap was the CRTL->RMS stdio veneer (src/vmsrms/crtl_rms_stdio.c) the driver's C
stdio routes through: it capped a single fwrite at one 16-bit FIX record
(0xFFFF), so a >64 KiB .OBJ/.LIS write could not go through it even though the
engine beneath supports it.

ovmx_crtl_fwrite: a request > 0xFFFF is now CHUNKED into successive sys$put
record writes. Byte-transparent: ovmx_crtl_fread is a 1-byte-per-$GET loop to
RMS$_EOF, so it reconstructs the exact byte stream regardless of record
boundaries. Refactored fopen's open+connect into a shared crtl_open_common.

Proof: tests/qemu/test_syssvc_crtl_rms_bigwrite.c (auto-gated by the required
"Kernel Executive (vms.ko via /dev/vms, QEMU)" job, which globs test_syssvc_*):
writes 200000 bytes (> 3 FIX records) through one fwrite, reads them back
byte-exact, and an INDEPENDENT ACP reader (sys$parse+sys$search + on-disk
rms_file_attr) sees the file with a genuine ODS-2 File ID — un-fakeable by a
ramfs. Host/x86_64-provable on the real /dev/vms; no Alpha rail. VERIFIED on the
k3s executive rail (OVMX_KTEST_ONLY=test_syssvc_crtl_rms_bigwrite): checks
1a-1h all pass.

SCOPE: a delete-on-close temp path (ovmx_crtl_tmpfile / FAB$M_TMD) was drafted
but its sys$close IO$_DELETE did not fire on the rail (rms_impl_close sets the
delete flag but the file survived) — descoped to its own item (vms-667b) rather
than ship a temp primitive that does not auto-delete. Random-access modes
(fseek/ftell/a/r+/w+) over the sequential RMS stream are filed as vms-a11.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018q4jvj6GCkdbYjRvpy7Vwu

* vms-126: test_syssvc_crtl_rms_bigwrite dismounts VDA0: — fix cross-suite mount-state leak (shard-3/6 red)

The bigwrite suite $MOUNTed VDA0: executive-global (idempotent) and never
$DISMOUNTed it. It runs in the SHARED Kernel-Executive QEMU guest boot, and by
md5(suite_name)%6 lands on shard 3/6 alongside test_syssvc_startup_service,
running before it. corpus_seed_lnm seeds SYS$SYSDEVICE -> VDA0:, so with VDA0:
left mounted, startup_service's RUN/DETACHED "/bin/sh" resolves through the ACP
(dcl_resolve_activatable_acp -> rms_file_attr): the device is mounted but
busybox /bin/sh is in the initramfs, not on ODS-2 -> SS$_NOSUCHFILE -> RMS$_FNF
-> acp_usable=1 -> correct INV-6 %DCL-E-IVIMAGE (host fallback forbidden) -> 13
RUN/$CREPRC fails. Without bigwrite (main / same-base #1085), every VDA0:-mounting
suite dismounts, VDA0: is unmounted when startup_service runs -> RMS$_ACC -> host
fallback finds busybox -> 50/0 green.

Nothing is exhausted and the file cleanup was already correct (BIGWR.DAT erased);
the leaked state is the VOLUME MOUNT. Fix: $DISMOUNT VDA0: in the done: cleanup,
mirroring test_syssvc_acp_mount/_channel — leave no shared mount state behind.
The chunking + File-ID coverage is unchanged.

(Follow-ons, not #1122 blockers: vms-9af6 — the KE shard harness should reset
executive mount state between suites so one suite can't leak into a co-tenant;
and the honest-error angle is INV-6-correct here, not a mislabel.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mZSxmiHPcUBuMNiVT5jXw

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@baron-3dl