VERSION(9P)
โจ NAME โจ
okay bestie, welcome to the VERSION(9P) page โ the main character here is version, and its whole job is literally โnegotiate protocol versionโ ๐
โจ
๐จ SYNOPSIS ๐จ
size[4] Tversion tag[2] msize[4] version[s]
size[4] Rversion tag[2] msize[4] version[s]
๐ฌ DESCRIPTION ๐ฌ
so the version request is the lil opening move that negotiates the protocol version and message size for the connection, and initializes the connection for I/O ๐ซถ. Tversion must be the first message sent on the 9P connection, and the client cannot issue any further requests until it has received the Rversion reply. the tag should be NOTAG (value (ushort)~0) for a version message. periodt.
the client suggests a maximum message size, msize โ thatโs the maximum length, in bytes, it will ever generate or expect to receive in a single 9P message ๐. this count includes all 9P protocol data, starting from the size field and extending through the message, but excludes enveloping transport protocols. the server responds with its own maximum, msize, which must be less than or equal to the clientโs value. thenceforth, both sides of the connection must honor this limit. no cap.
the version string identifies the level of the protocol. the string must always begin with the two characters 9P ๐. if the server does not understand the clientโs version string, it should respond with an Rversion message (not Rerror) with the version string the 7 characters unknown. yep, exactly that.
the server may respond with the clientโs version string, or a version string identifying an earlier defined protocol version. currently, the only defined version is the 6 characters 9P2000 ๐. version strings are defined such that, if the client string contains one or more period characters, the initial substring up to but not including any single period in the version string defines a version of the protocol. after stripping any such period-separated suffix, the server is allowed to respond with a string of the form 9Pnnnn, where nnnn is less than or equal to the digits sent by the client. iykyk.
the client and server will use the protocol version defined by the serverโs response for all subsequent communication on the connection ๐ซ.
a successful version request initializes the connection. all outstanding I/O on the connection is aborted; all active fids are freed (clunked) automatically. the set of messages between version requests is called a session. thatโs the vibe check on sessions, bestie.
๐ ENTRY POINTS ๐
Fsversion (see 9pclient(3)) generates version messages; it is called automatically by fsmount ๐.
๐ thatโs the whole page, bestie โ the footer source/version line is VERSION(9P), and thereโs no extra date printed on this page, so no invented tea. periodt. ๐
๐ฆ where this page comes from
- alpine 3.24: plan9port-doc 0_git20260208-r0 ยท LPL-1.02
- arch rolling: plan9port 20261021-2 ยท custom
- nixos 26.05: plan9port 0-unstable-2025-11-10
- nixos 26.05: plan9port-wayland 0-unstable-2025-11-26
- nixpkgs unstable: plan9port 0-unstable-2025-11-10
- nixpkgs unstable: plan9port-wayland 0-unstable-2025-11-26
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms