From def843b2f59b867ee9b1d501f559f59fb335d4cc Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Thu, 27 Aug 2026 15:32:02 -0300 Subject: 9p: serve the acme tree over 9P2000 on a unix socket, beside the mount Step 4 of the 9P chain (docs/9p.typ 12.4, docs/registry.typ 9P-15/16/17/4/5). src/9p.zig is a base 9P2000 codec and a SANS-IO server: it never touches a descriptor, takes no allocator, starts no thread, and builds for wasm32-freestanding and riscv32-freestanding. That is what lets the same code serve a unix socket here and a UART on the board later. Server(comptime fs: type) duck-typed on fs.Req/fs.Reply/fs.Reply.Attr, so it never imports acmefs and acmefs never learns 9P init{ in, out, root } the caller owns the buffers; msize is derived retry/next/reply the three fs_service.Transport ops, by name push/output/wrote/hangup bytes in, bytes out, partial writes supported next() is a PUMP, not one-message-one-request: a 3-element Twalk is three lookups, Topen|OTRUNC is a setattr then an open, Tversion is none at all. Decisions that were open and are now taken, each recorded in the file: * qid.version is ALWAYS 0, which makes Linux set P9L_DIRECT and skip its cache -- the 9P equivalent of the FOPEN_DIRECT_IO fuse.zig relies on. * Every Rread is clamped to the client's count. An over-long one is a hard -EIO in Linux, not a truncation. * Rerror carries Linux's exact strerror text (registry 9P-4 option A), so a mount recovers the errno instead of ESERVERFAULT. Asserted as literals, because a typo there is 'Unknown error 526' on every mount. * `.` and `..` are resolved BY THE SERVER. Under FUSE the kernel does it and acmefs says so; 9P has no kernel, and forwarding `..` as a lookup would break every client that normalises a path. * Topen checks the perm bits itself. Under FUSE the kernel enforced them; over 9P nobody is above the server, and `errors` would have been readable. * Tcreate and Tremove are Rerror: `new/` creates a pane on WALK, so the capability exists and is not spelled Tcreate. THE INTEGRATION BUG, which was not in the protocol: the daemon's push_fs_reply sent every reply to the FUSE mount, whose park table has no 9P tag, so it dropped it -- Tversion worked (no core involved) and Tattach hung forever. That is exactly the 'no routing origin for the 9P descriptor' cell in the layering table of docs/9p.typ. Session.fs_origin now carries the transport that asked. Proved with plan9port against a live daemon serving BOTH transports at once: 9p ls / and /1, read index/ctl/tag, write /1/body, stat, a walk through /1/../index, pane creation through `new/body`, and the two refusals arriving as strings -- 'permission denied' and 'No such file or directory' -- confirmed on the raw wire as Rerror text rather than numbers. A write over 9P reads back through FUSE and a write through FUSE reads back over 9P. msize 8192, 34,072 bytes per connection (Server 9,488 + in 8,192 + out 16,384, out being two msize so that every reply is infallible), four connections. zig build unit-test: 468 tests before, 503 after. --- docs/9p.pdf | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs/9p.pdf') diff --git a/docs/9p.pdf b/docs/9p.pdf index 0660b398..9d2dc054 100644 --- a/docs/9p.pdf +++ b/docs/9p.pdf @@ -2773,12 +2773,12 @@ F endstream endobj 748 0 obj -<> +<> endobj 749 0 obj <> stream -Typst 0.15.1en2026-08-27T14:50:53-03:002026-08-27T14:50:53-03:0012application/pdfNc4gGcVFwBThPG3ZsCSPxg==Nc4gGcVFwBThPG3ZsCSPxg==proof1.7 +Typst 0.15.1en2026-08-27T16:19:44-03:002026-08-27T16:19:44-03:0012application/pdfHljsDPgWqw9TTnj4ezsOYg==HljsDPgWqw9TTnj4ezsOYg==proof1.7 endstream endobj 750 0 obj @@ -3538,7 +3538,7 @@ xref 0000178455 00000 n 0000179529 00000 n trailer -<> +<> startxref 179734 %%EOF \ No newline at end of file -- cgit v1.3