diff --git a/AI.md b/AI.md index 6cc1666..d252fa8 100644 --- a/AI.md +++ b/AI.md @@ -11,7 +11,7 @@ When the user says this is a new chat or asks to continue mars-nwe work, first read this file before proposing patches or making assumptions. Then ask for, or use, the current project status that the user pasted into the chat. -## Current handoff status after patch 0220 +## Current handoff status after patch 0221 The current accepted patch line in this chat is expected to include: @@ -19,12 +19,13 @@ The current accepted patch line in this chat is expected to include: - redesign documentation patches `0177` through `0198`; - endpoint-audit/documentation patches `0199` through `0219`; - redesign clarification patch `0220-docs-record-print-queue-redesign-link.patch`; -- latest expected patch name: `0220-docs-record-print-queue-redesign-link.patch`. +- endpoint-audit patch `0221-docs-audit-ncp-extension-stubs.patch`; +- latest expected patch name: `0221-docs-audit-ncp-extension-stubs.patch`. When continuing in a new chat, first ask the user which patch was actually last -applied. If they confirm `0220`, build the next patch as `0221-...` against a -tree that already contains `0220`. If they only applied through `0219`, apply or -rebuild `0220` before continuing endpoint work. If any patch failed or was skipped, rebuild +applied. If they confirm `0221`, build the next patch as `0222-...` against a +tree that already contains `0221`. If they only applied through `0220`, apply or +rebuild `0221` before continuing endpoint work. If any patch failed or was skipped, rebuild against the last confirmed applied patch instead of assuming the file in `/mnt/data` was accepted. @@ -61,6 +62,20 @@ High-level NCP architecture direction: - Queue is a strong candidate for a future `nwqueue` provider/process, but first split it logically from bindery. + +NCP Extension note from patch `0221`: + +- SDK `0x2222/36` / wire `0x24` NCP Extension information and SDK + `0x2222/37` / wire `0x25` Execute NCP Extension are source-stub-audited as + planned NetWare 4.x extension-registration work. +- `src/nwconn.c` now contains disabled `MARS_NWE_4` stubs for `36/00` through + `36/06` and direct `37`. They intentionally return `0xfb` if ever enabled + without a real extension registry/provider. +- Future owner is an extension registry/provider. Do not route extension + payloads through `nwserv` as a data-plane broker; `nwserv` remains only + control-plane/supervision/registry. +- The next patch number should be `0222` if `0221` was applied. + Print/queue redesign note from patch `0220`: - Do not describe printing as entirely absent. Queue-backed printing already @@ -211,24 +226,21 @@ Schema/import direction: Latest endpoint audit note: -- Patch `0218` audits SDK `0x2222/17` / wire `0x11` direct Print/Spool as a - NetWare 2.x/3.x/4.x compatibility family. No active top-level source - handler exists for these legacy direct spool NCPs, so the documented selector - slots `17/00` Write To Spool File, `17/01` Close Spool File, `17/02` Set - Spool File Flags, `17/03` Spool A Disk File, `17/06` Get Printer Status, - `17/09` Create Spool File, and `17/10` Get Printer's Queue are recorded as a - disabled `#if 0` source stub in `src/nwconn.c`. -- Do not describe printing as wholly unimplemented: queue-based printing already - exists through print queues, `Q_UNIX_PRINT`, and queue-job close/service - paths. The audited gap is the older direct SDK 17 spool/printer NCP family. -- Future direct-spool implementation should reuse or bridge to the existing - queue printing machinery where possible, but it does not belong to `nwnds`. - The stub is intentionally inactive and has no runtime effect. +- Patch `0221` audits SDK `0x2222/36` / wire `0x24` NCP Extension + information and SDK `0x2222/37` / wire `0x25` Execute NCP Extension as + planned NetWare 4.x extension-registration work. +- `src/nwconn.c` contains disabled `MARS_NWE_4` stubs for `36/00` through + `36/06` and direct `37`; they are documentation/source markers only and do + not change the default runtime. +- Future implementation needs an extension registry/provider. `nwserv` may + supervise/register providers but must not become the data-plane broker for + extension payloads. +- Previous print note still applies: direct `17/xx` spool NCPs are only the + old direct-spool compatibility surface; queue-backed printing already exists. -The next patch number should be `0220` if `0219` was applied. Likely next +The next patch number should be `0222` if `0221` was applied. Likely next blocks are deeper `0x2222/23` bindery/property/admin subfunction coverage, -SDK `0x2222/36`/`37` NCP Extension scope, SDK `0x2222/90` scope, or another -user-selected endpoint family. +SDK `0x2222/90` scope, or another user-selected endpoint family. ## Patch workflow diff --git a/REDESIGN.md b/REDESIGN.md index f8b9207..f485c03 100644 --- a/REDESIGN.md +++ b/REDESIGN.md @@ -721,6 +721,7 @@ namespace path, directory handle, name-space operations file file handle and read/write/open/close operations salvage deleted-file scan/recover/purge backend AFP AFP metadata and AFP namespace adapter +extension future NCP Extension registry/executor for 36/37, if enabled ``` This is a design target, not a demand to move files immediately. The important @@ -816,6 +817,24 @@ cases out of `nwbind.c`. It needs an explicit contract for: Until those contracts are clear, `nwqueue` should remain a design target, not an immediate functional change. +#### NCP Extension provider + +The `0x2222/36` NCP Extension information family and the direct +`0x2222/37` Execute NCP Extension call are a planned NetWare-4.x-era +compatibility surface, not a reason to route arbitrary extension payloads +through `nwserv`. + +If implemented later, they should use a small extension registry/provider that +can report registered extension numbers, names, versions, custom data, maximum +data sizes, and dispatch `37` execution payloads to explicitly registered +handlers. `nwserv` may supervise provider processes and publish control-plane +registration information, but it must not become the normal data-plane broker +for extension request/reply payloads. + +Until such a registry exists, the source should keep `36`/`37` behind disabled +`MARS_NWE_4` stubs that return unsupported rather than pretending that arbitrary +NLM extension execution is available. + #### Direct print/spool NCPs versus existing queue printing Printing needs a small extra distinction because mars-nwe already has diff --git a/TODO.md b/TODO.md index 35ab681..03ac95a 100644 --- a/TODO.md +++ b/TODO.md @@ -215,14 +215,17 @@ Present in the code but not yet fully endpoint-audited: exists through print queues, `Q_UNIX_PRINT`, and queue-job close/service paths. Any future direct-spool implementation should reuse that queue printing machinery where possible, and it does not belong to `nwnds`. +- SDK `0x2222/36` and `0x2222/37` / wire `0x24` and `0x25` NCP Extension + are source-stub-audited as a NetWare 4.x extension-registration family. + Patch 0221 records the documented `36/00`..`36/06` information selectors and + direct `37` execute-extension call behind `MARS_NWE_4` in `src/nwconn.c`. + There is no active extension registry/provider yet, and `nwserv` must remain + a control-plane registry/supervisor rather than a data-plane broker for + extension payloads. SDK-listed blocks that do not currently show a top-level handler in `src/nwconn.c`: -- SDK `0x2222/36` and `0x2222/37` / wire `0x24` and `0x25` NCP Extension - families. The PDF lists extension-info and execute-extension calls; no - top-level handlers have been identified yet. Bucket by generation before - adding any `#if MARS_NWE_4` stubs. - SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire `0x4f`, `0x54`, and `0x55` are listed by the SDK/PDF for later file/extended-data functions, but no top-level handlers have been identified yet. diff --git a/src/nwconn.c b/src/nwconn.c index 27e3971..bc17809 100644 --- a/src/nwconn.c +++ b/src/nwconn.c @@ -6140,6 +6140,120 @@ static int handle_ncp_serv(void) } } break; +#if MARS_NWE_4 + case 0x24 : { /* NCP Extension information, SDK 36 / wire 0x24. */ + /* + * NCP 0x2222/36 NCP Extension information group. + * + * Source outcome: no active handler existed for this + * NetWare 4.x/5.x extension-registration family. The + * current project scope plans through NetWare 4.x, so keep + * these selector slots as disabled MARS_NWE_4 stubs until + * a real extension registry/provider exists. + * + * Request handoff: direct NCP 36 carries the + * SubFuncStrucLen word before requestdata[0], and + * requestdata[0] is the NCP Extension SubFuncCode. + * Reply ownership would remain local: Completion plus the + * documented information payload, with no routing through + * nwserv as a data-plane broker. + */ + int ext_sub = (requestlen > (int)sizeof(NCPREQUEST)) + ? (int)requestdata[0] : -1; + + switch (ext_sub) { + case 0x00: /* 36/00 Get NCP Extension Information old. + * Request: SubFuncCode=0, NCPExtensionNumber. + * Reply: extension number, major/minor/revision, + * name length/name, and 32-byte CustomData. + * Future owner: extension registry/provider. + */ + completition = 0xfb; + break; + + case 0x01: /* 36/01 Get NCP Extension Maximum Data Size. + * Request: SubFuncCode=1, NCPExtensionNumber. + * Reply: maximum extension request/reply data + * size for the selected registered extension. + * Future owner: extension registry/provider. + */ + completition = 0xfb; + break; + + case 0x02: /* 36/02 Get NCP Extension Information by Name. + * Request: SubFuncCode=2, NameLength, Name. + * Reply: same information block as 36/00. + * Future owner: extension registry/provider. + */ + completition = 0xfb; + break; + + case 0x03: /* 36/03 Get Number of Registered NCP Extensions. + * Request: SubFuncCode=3. + * Reply: NumberOfNCPExtensions. + * Future owner: extension registry/provider. + */ + completition = 0xfb; + break; + + case 0x04: /* 36/04 Get NCP Extension Registered Verbs List. + * Request: SubFuncCode=4, StartingNumber. + * Reply: ReturnedListCount, NextStartNumber, and + * NCP extension numbers. + * Future owner: extension registry/provider. + */ + completition = 0xfb; + break; + + case 0x05: /* 36/05 Return NCP Extension Information. + * Request: SubFuncCode=5, NCPExtensionNumber. + * Reply: information block for the exact + * registered extension number. + * Future owner: extension registry/provider. + */ + completition = 0xfb; + break; + + case 0x06: /* 36/06 Return NCP Extension Maximum Data Size. + * Request: SubFuncCode=6, NCPExtensionNumber. + * Reply: maximum data size for the exact + * registered extension number. + * Future owner: extension registry/provider. + */ + completition = 0xfb; + break; + + default: completition = 0xfb; + break; + } + } + break; + + case 0x25 : { /* Execute NCP Extension, SDK 37 / wire 0x25. */ + /* + * NCP 0x2222/37 Execute NCP Extension. + * + * Source outcome: no active handler existed for executing + * registered NCP extensions. This is a planned NetWare + * 4.x compatibility surface only if mars-nwe eventually + * grows an extension registry/provider. + * + * Request: SubFuncStrucLen, NCPExtensionNumber, RequestData. + * CLIB-style extension payloads may begin with + * MaximumReplyLength, RequestBuffer, and RequestBufferLength, + * but the concrete payload is owned by the selected + * registered extension handler. + * + * Reply: provider-defined ReplyBuffer, often with a + * CLIB-style ReplyBufferLength prefix. + * Future owner: extension registry/provider, not nwserv as + * a data-plane payload broker. + */ + completition = 0xfb; + } + break; +#endif + case 0x3b : /* commit file to disk */ case 0x3d : /* commit file */ {