From b3299b6608ab015bf4d368b968c64da4f81ca3a4 Mon Sep 17 00:00:00 2001 From: alice Date: Fri, 28 Aug 2026 16:43:47 +0000 Subject: [PATCH 1/3] =?UTF-8?q?vms-67f:=20baseline=20=E2=80=94=20TCP/IP=20?= =?UTF-8?q?Services=20layered-product=20roadmap+buildplan=20work?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From a8a8e573edc3f03bb4b39c612e7953e1dd48fbe3 Mon Sep 17 00:00:00 2001 From: alice Date: Fri, 28 Aug 2026 16:45:45 +0000 Subject: [PATCH 2/3] =?UTF-8?q?vms-67f:=20build=20plan=20=E2=80=94=20TCP/I?= =?UTF-8?q?P=20Services=20as=20first-class=20layered-product=20kit?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reflect the operator ruling (2026-08-28): TCP/IP Services is a first-class layered-product deliverable (own kit, own release line, OpenSSH bundled in), distinct from the base OVMX OS but living in src/vmstcpip/. - design-tcpip-services-ovmx.md: new §0 (operator ruling + base-OS/layered split), §6 Packaging rewritten and grounded in the actual kit mechanism (tools/ovmx_kit_pack.c OVMXKIT1 container, src/product PRODUCT.EXE + product DB, distinct 'OVMX TCPIP' product identity, ovmx-tcpip.kit artifact), §9 operator calls marked resolved. - building.md: new 'Base OS vs. Layered Products (kits)' section grounding the layered-product build/install flow; DECnet noted as the same pattern. --- docs/building.md | 30 +++++++++ docs/design-tcpip-services-ovmx.md | 101 ++++++++++++++++++++++++----- 2 files changed, 116 insertions(+), 15 deletions(-) diff --git a/docs/building.md b/docs/building.md index df4f96e59..b5d315d61 100644 --- a/docs/building.md +++ b/docs/building.md @@ -81,6 +81,36 @@ The bootable image includes: - Initramfs with busybox, static OVMX binaries, kernel modules - `init-wrapper.sh` as PID 1: mounts filesystems, loads vms.ko + vmsfs.ko, launches ovmx_init +## Base OS vs. Layered Products (kits) + +OVMX is structured like real OpenVMS: a **base operating system** plus separately-installable +**layered products** (TCP/IP Services, DECnet, …). Each is packed as its own PCSI-equivalent +**kit** with a distinct product identity, and installed onto the target system by `PRODUCT +INSTALL` — which registers each product separately in `SYS$SYSTEM:VMS$PRODUCT_DATABASE.DAT`, so +`PRODUCT SHOW PRODUCT` lists them individually. + +- **Kit format + packer:** `src/libvms/include/ovmx_kit_format.h` (the `OVMXKIT1` container) and + `tools/ovmx_kit_pack.c` (the host packer). Product name shape is *vendor + arch-code + product*. +- **Installer + product DB:** `src/product/product.c` (`PRODUCT.EXE`), `src/product/ovmx_product_db.h`. +- **Base OS kit** — `OVMX X86VMS VMS` / `OVMX VAXVMS VMS`, packed as `ovmx-os.kit` by + `distro/Dockerfile.bootable` and shipped by `tools/cut-release.sh`. +- **Layered-product kit** — packed by the *same* mechanism with its own identity and shipped as a + separate artifact on its own release line: + + ```bash + # (from a staging tree of the product's images/templates) + ovmx_kit_pack pack ovmx-tcpip.kit "X86VMS TCPIP" # -> product "OVMX X86VMS TCPIP" + # on the target system: + $ PRODUCT INSTALL TCPIP # registers a second product; SHOW PRODUCT lists OS + TCPIP + ``` + +**TCP/IP Services** (`src/vmstcpip/`, rd epic `vms-67f`) is the first layered product, and +**bundles the OpenSSH port** into its kit (as real OpenVMS ships SSH inside TCP/IP Services). +Its IP engine is the substrate kernel's `AF_INET` stack; faithfulness lives in the userspace +product surface (`TCPIP$CONFIG`-equivalent, the `TCPIP$*` logicals, the `BGn:` device + sockets +veneer). Full design: `docs/design-tcpip-services-ovmx.md`. **DECnet** (`vms-30e`) follows the +identical layered-product kit pattern. + ## Kernel Modules Built out-of-tree against installed kernel headers. Not integrated into CMake. diff --git a/docs/design-tcpip-services-ovmx.md b/docs/design-tcpip-services-ovmx.md index cf1607e4d..3ccab8332 100644 --- a/docs/design-tcpip-services-ovmx.md +++ b/docs/design-tcpip-services-ovmx.md @@ -1,9 +1,44 @@ # Design — TCP/IP Services for OVMX -**Status:** design / teed for the 1.0 march (new networking lane, parallel to clustering + parity). -**Companion:** `docs/design-decnet-ovmx.md` (shares the networking seam ruling in §2). -**Author of record:** conductor, 2026-08-11. Grounds: OVMX standing rulings + VSI TCP/IP -Services public docs (docs.vmssoftware.com) + a full `origin/main` surface inventory. +**Status:** active — **first-class layered-product deliverable** (operator ruling 2026-08-28, +below). Networking lane on the 1.0 march, parallel to clustering + parity. +**Companion:** `docs/design-decnet-ovmx.md` (shares the networking seam ruling in §2 and the +layered-product kit model in §6 — DECnet is the same pattern). +**Author of record:** conductor, 2026-08-11; layered-product framing 2026-08-28. Grounds: OVMX +standing rulings + VSI TCP/IP Services public docs (docs.vmssoftware.com) + a full `origin/main` +surface inventory (kit mechanism re-grounded against `tools/ovmx_kit_pack.c` + `src/product/`). + +--- + +## 0. Operator ruling — first-class layered product (2026-08-28) + +TCP/IP Services for OVMX (rd epic **vms-67f**, now **p1**) is a **first-class layered-product +deliverable** — *distinct from the base OVMX OS, but part of this repo* (`src/vmstcpip/`). This +mirrors how real OpenVMS is structured: a **base operating system** plus separately-installable +**layered products** (TCP/IP Services, DECnet, …), each shipping as its own kit on top of the +executive. + +- **Its own kit, its own release line.** TCP/IP Services is packed as a **distinct product kit** + (its own product identity in the PCSI-equivalent product database), layered on the base OVMX + OS — not folded into the base OS image. See §6, which grounds this in the actual OVMX kit + mechanism (`ovmx_kit_pack` / `PRODUCT INSTALL`). +- **OpenSSH bundles INTO this product**, exactly as real OpenVMS ships SSH *inside* TCP/IP + Services — **not** as a side-riding standalone feature. The earlier sshd-over-`BGn:` work + (`vms-843` native VMSSSHD, `vms-4bf` de-veneer) was **not a mistake**: it was a valid OpenVMS + source-support **oracle** that validated the `BGn:` socket surface (the `DECC$SOCKET`/`$QIO` + model, honest under INV-6). But as a *shippable feature* it is pointless outside the layered + product, so it re-homes here (§5 Phase 4, §6) and is packaged **into** the TCP/IP Services kit. +- **The config/management half is the gap to build.** Networking today only rides the substrate + `ETH0:` device; the VMS-faithful **configuration + management plane** — `TCPIP$CONFIG`-equivalent, + the `TCPIP$*` system logical names, and durable VMS-faithful IP config — does not yet exist. + That is the active work: rd rungs **vms-85b** (config/management), **vms-cb0** (bundle OpenSSH + into the kit), **vms-f394** (kit + release integration), plus **vms-843** (native VMSSSHD). +- **Base-OS-vs-layered-product split (the load-bearing distinction).** The **base OS** owns the + executive, the device namespace, the `$QIO`/process framework, and the runtime NIC-as-VMS-device + (`EWA0:`). The **layered product** owns everything TCP/IP-specific in userspace: the INET/`BGn:` + device shim, the sockets veneer, the management plane, the services, and OpenSSH. The **IP + engine itself is the substrate** — the Linux (or NetBSD) kernel's `AF_INET`/`AF_INET6` stack — + and **faithfulness lives entirely in the userspace product surface** on top of it (§1, §2). --- @@ -122,13 +157,46 @@ Consequences under the standing rulings: | **4. Auxiliary server + services** | Auxiliary server launches BIND resolver + TELNET/FTP servers (+ re-wired `VMSSSHD.EXE`); inbound connect from host succeeds. | Needs tap or hostfwd from Phase 0. | | **5. e2e QEMU gate** | CI gate: booted VM gets an address, resolves a name, PINGs the gateway, FTP round-trips a file; **honest-degradation** sub-test asserts `SS$_NOSUCHDEV` with no NIC / no `/dev/vms`. | Release proof. | -## 6. Packaging - -A **layered-product kit** (`TCPIP$`) installed via the Alpha/PCSI model (`vms-718`): -`TCPIP$STARTUP.COM` invoked from the STARTUP phases (`vms-46c`), gated to **not** announce -running if no NIC is present (no LARP). Kit contents: management images, INET/BG driver-shim, -service daemons, `TCPIP$CONFIG.COM`, DCL tool images, the `TCPIP$*` logical-name and database -templates. Config lives under `TCPIP$ETC:`/`SYS$SYSTEM:TCPIP$*.DAT`. +## 6. Packaging — a distinct layered-product kit (grounded in the OVMX kit mechanism) + +TCP/IP Services ships as a **separate product kit**, layered on the base OVMX OS — built and +installed by the *same* PCSI-equivalent mechanism the base OS already uses, just with its own +product identity. This is not a new build mechanism; it is a second consumer of the existing one. + +**How the base OS kit is built today (the model to mirror).** `tools/ovmx_kit_pack.c` packs a +staging tree into a single self-identifying kit container (`OVMXKIT1`, `src/libvms/include/ +ovmx_kit_format.h`) whose product name has the shape *vendor + arch-code + product* — the base +OS is **`OVMX X86VMS VMS`** (x86-64) / **`OVMX VAXVMS VMS`** (VAX), echoing the Alpha oracle's +`DEC AXPVMS VMS` shape (`tools/cross-vax/build-os-kit-vax.sh`). `distro/Dockerfile.bootable`'s +kit-packing stage produces `ovmx-os.kit` and its manifest; `tools/cut-release.sh` ships that kit +as a release artifact (`ARTIFACT_ORDER=(… ovmx-os.kit)`). `PRODUCT INSTALL` (`src/product/ +product.c`, `PRODUCT.EXE`) reads a kit and registers the product in the per-system PCSI-equivalent +**product database** (`SYS$SYSTEM:VMS$PRODUCT_DATABASE.DAT`, `src/product/ovmx_product_db.h`), so +`PRODUCT SHOW PRODUCT` lists it. + +**The TCP/IP Services kit does exactly this, with its own identity.** Packed by the same +`ovmx_kit_pack pack " TCPIP"` invocation, it becomes a **distinct +product** — e.g. `OVMX X86VMS TCPIP` (and `OVMX VAXVMS TCPIP` / an Alpha identity per arch) — +carried as its own release artifact (`ovmx-tcpip.kit`, alongside `ovmx-os.kit`) with its own +release line (`vms-f394`). Because `PRODUCT.EXE` registers by product identity, installing it +adds a **second row** to `VMS$PRODUCT_DATABASE.DAT`, so `PRODUCT SHOW PRODUCT` lists the base OS +**and** TCP/IP Services as separate products — exactly the real-OpenVMS layered-product shape. + +**Kit contents:** the management images and `TCPIP$CONFIG.COM`, the INET/`BGn:` driver-shim, the +sockets-veneer RTL, the service daemons, the DCL tool images (PING/TELNET/FTP), the `TCPIP$*` +logical-name + config-database templates (seeded once via `OVMX_KIT_ENTRY_FLAG_SEED_ONCE` so an +upgrade never clobbers site config), **and the OpenSSH port** (`VMSSSHD.EXE` + client) bundled in +here rather than in the base OS. Config lives under `TCPIP$ETC:` / `SYS$SYSTEM:TCPIP$*.DAT`. + +**Startup + honest degradation.** `TCPIP$STARTUP.COM` is invoked from the STARTUP phases +(`vms-46c`) *only when the product is installed*, and is gated to **not** announce running if no +NIC is present (no LARP — INV-6). A base-OS image with no TCP/IP kit installed simply has no +`TCPIP$*` product, no `BGn:`, and `$ASSIGN TCPIP$DEVICE:` → `SS$_NOSUCHDEV` — the honest layered +absence, not a per-process fake. + +**DECnet is the same pattern.** DECnet Phase IV (`vms-30e`, `docs/design-decnet-ovmx.md`) packs +its own `OVMX DECNET` kit by the identical mechanism and registers as a third product — +the general OVMX layered-product model, of which TCP/IP Services is the first instance. ## 7. Testing & oracle @@ -146,8 +214,11 @@ the DCL **verb table** (the `TCPIP` verb front-end; one owner per week, append-o through the bridge, never a parallel edit). Runtime NIC touches `distro/boot/run-qemu.sh` + `Dockerfile.bootable` (Phase 0, coordinate with boot owner). -## 9. Open operator calls +## 9. Operator calls — resolved -1. **Service breadth for 1.0.** Recommend: resolver + TELNET + FTP + SSH in-scope; SMTP/NTP/ - SNMP/NFS/LPD deferred to post-1.0. (Conductor default unless overridden.) -2. **Kit branding** under INV-0 — "TCP/IP Services for OVMX" proposed; confirm. +1. **Layered-product structure (resolved 2026-08-28, §0).** First-class layered product, its own + kit + release line, OpenSSH bundled in, config/management the gap. vms-67f → p1. +2. **Service breadth for 1.0 (resolved, `vms-4ad`).** Resolver + TELNET + FTP + SSH in-scope; + SMTP/NTP/SNMP/NFS/LPD deferred to post-1.0. +3. **Kit branding under INV-0 (resolved, `vms-79fd`).** "TCP/IP Services for OVMX" (OVMX is our + mark); the machine product identity is `OVMX TCPIP` (§6). Never badged as VSI/HP. From 7620fe7698cdc2c64976b2307752f686a71de44a Mon Sep 17 00:00:00 2001 From: alice Date: Fri, 28 Aug 2026 16:48:27 +0000 Subject: [PATCH 3/3] =?UTF-8?q?vms-67f:=20reconcile=20roadmap=20=E2=80=94?= =?UTF-8?q?=20TCP/IP=20Services=20surfaces=20as=20first-class=20deliverabl?= =?UTF-8?q?e?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Regenerate the rd-derived roadmap GENERATED block (INV-LEDGER — not hand-edited) so the promoted TCP/IP networking epic (vms-67f, now p1) surfaces with its full rung tree: the 1.0-gate workstream row moves 7/12 -> 12/26 (5 blocked), matching the expanded config/management + kit + OpenSSH-bundle decomposition. Also refine the editorial workstream summary in reconcile.py (GATE_EPICS config, not the generated block) to describe the layered product: its own installable kit on the base OS, config/management, and a bundled SSH. This flows to the canonical export + public site view only; the site publish is DEFERRED to the conductor (INV-0). Ledger drift gate (check_roadmap_block.py), reconcile --check idempotency, and the collapse-guard test all pass. --- docs/release-roadmap-to-1.0.md | 4 ++-- tools/roadmap/reconcile.py | 5 +++-- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/release-roadmap-to-1.0.md b/docs/release-roadmap-to-1.0.md index e2b32eff4..b007c2e67 100644 --- a/docs/release-roadmap-to-1.0.md +++ b/docs/release-roadmap-to-1.0.md @@ -102,11 +102,11 @@ only our forks target. | Workstream | Epic | Lands by | Status | Done/Total | Blocked | |---|---|---|---|---:|---:| -| Executive substrate | `vms-6b8` | 0.5 | in progress | 17/22 | 0 | +| Executive substrate | `vms-6b8` | 0.5 | in progress | 17/23 | 0 | | Command-surface parity | `vms-8ad` | continuous | in progress | 37/73 | 0 | | Self-hosting toolchain | `vms-678` | 0.5→0.9 | in progress | 16/23 | 2 | | Cluster configuration | `vms-098` | 0.5→0.9 | in progress | 3/12 | 8 | -| TCP/IP networking | `vms-67f` | 0.5→0.9 | in progress | 7/12 | 2 | +| TCP/IP networking | `vms-67f` | 0.5→0.9 | in progress | 12/26 | 5 | | DECnet Phase IV | `vms-30e` | 0.9 | in progress | 5/11 | 5 | | Kernel substrate | `vms-19e` | 0.5 | in progress | 5/8 | 1 | | VAX as a first-class platform | `vms-8e8` | 0.5→0.9 | in progress | 86/95 | 1 | diff --git a/tools/roadmap/reconcile.py b/tools/roadmap/reconcile.py index 461621cde..989547315 100644 --- a/tools/roadmap/reconcile.py +++ b/tools/roadmap/reconcile.py @@ -109,8 +109,9 @@ "Provision a node into a cluster the VMS way: SYSGEN parameters, AUTOGEN, " "CLUSTER_AUTHORIZE, and CLUSTER_CONFIG.", "0.5-0.9"), ("vms-67f", "TCP/IP networking", - "A VMS-faithful IP layered product: the network device, sockets, the resolver, " - "and the client tools.", "0.5-0.9"), + "A VMS-faithful IP networking layered product — its own installable kit on the base " + "operating system: the network device, sockets, configuration and management, the " + "resolver, the client tools, and a bundled SSH.", "0.5-0.9"), ("vms-30e", "DECnet Phase IV", "Clean-room DECnet: SET HOST and file transfer to and from a lab node.", "0.9"), ("vms-19e", "Kernel substrate",