Merge nucleic/olive-jade-civet-rznt into dev

This commit is contained in:
2026-07-29 00:25:53 -07:00
parent 4f324297ed
commit dcb86fab45
2 changed files with 18 additions and 11 deletions
+3 -3
View File
@@ -67,9 +67,9 @@ for, and nothing above it should move. These three are different:
| Finding | Consequence |
| --- | --- |
| No container enumeration, stats, or pty in the SDK | **Not fatal** — `wslc.exe` has all three and addresses containers by name, so `WslcFacade` becomes a hybrid (SDK hot path + CLI cold paths). Confirmed by the native header and the API reference, and publicly reported in [microsoft/WSL#41024](https://github.com/microsoft/WSL/discussions/41024), which Microsoft has not answered. |
| No create-or-attach on `Session` | Still open. The native-only `WSLC_CONTAINER_START_FLAG_ATTACH` may be it; the C# `Start()` takes no flags. Needs a live answer before item 11. |
| No gateway address anywhere on the API | §5's primary transport must source it from `GetAdaptersAddresses` over the `vEthernet (WSL)` adapter instead. If a `Bridged` container can't reach the host there, promote the AF_HYPERV/AF_VSOCK fallback. |
| No container enumeration, stats, pty or attach in the SDK | **Not fatal, and not CLI-only.** `wslcsdk.dll` wraps `WSLCCompat.idl` (the stable SDK surface), which genuinely lacks them; they all exist on `wslc.idl`, the service-internal COM interface `wslc.exe` calls — `ListContainers`, `Stats`, `ResizeTty`, `OpenContainer`/`Attach`, `OpenSessionByName`, and `IWSLCVirtualMachine::GetId` (the VM GUID for AF_HYPERV). Both IDLs are open source. Internal COM vs. CLI is an undecided trade-off — see §13.1. |
| No create-or-attach on `Session` | **Answered:** `IWSLCSessionManager::OpenSessionByName` / `EnterSession` / `ListSessions` exist on the internal interface. Reattach (§2.3) is mechanically possible; what remains is choosing the surface. |
| No gateway address anywhere on the API | Source it from `GetAdaptersAddresses` over the `vEthernet (WSL)` adapter — **or skip TCP entirely**: `IWSLCVirtualMachine::GetId` returns the VM GUID, so §5's AF_HYPERV/AF_VSOCK path (true vsock parity with macOS) is directly reachable rather than being upside. |
| No uid on `ProcessSettings` | Recoverable, and already planned for: exec wraps argv in `setpriv`/`su agent -c`. Interceptors and nash don't care about the numeric uid (§3.2). |
---