mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity

docs: audit NCP extension endpoint stubs

Browse Source
This commit is contained in:
OpenAI
2026-06-02 16:02:58 +00:00
committed by Mario Fetka
parent 2216c67522
commit 2d5339aba5
4 changed files with 173 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
AI.md
View File

@@ -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

19
REDESIGN.md
View File

@@ -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

11
TODO.md
View File

@@ -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.

114
src/nwconn.c
View File

@@ -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 */
{