The previous implementation assumed that you can't attach more than once. This is clearly wrong, Tattach and Twalk are the two ways to obtain new fids. This drops the error on subsequential attach and making the test "multiple attach" passes.

at the start of the loop nwqid is 0, so if the first component can't be opened nwqid becomes -1 and since it's not 0, we end up calling np_walk with -1 as length. This in turns converts it back to uint16_t and we generate an invalid packet. The solution is to not decrement nwqid at all, it fixes all the current tests case and is the correct behaviour that the rest of the code expects.

disallow empty path, the dot or components which contains the path separator ('/'). The current implementation transforms these into a "can't open" type of failure, I'm unsure if we want to turn these into hard Rerror.

Implement Topen plus some basic testing. ORCLOSE (remove file when the fid is clunked) is mapped to O_CLOEXEC and tried to be honoured on fid_free. "vanilla" 9P2000 uses reads on directories to list the entries while 9P2000.L (and .U too possibly) introduces an explicit Treaddir. I'm planning to support 9P2000-style read-on-dir but not yet.

I've finally made up my mind regarding the qid and fid handling. fids are fine as they currently are, I've just added some comments to don't forget the meaning of the iomode and fd fields. The values KFIO_W/R are new and will be soon used by the (soon to be added) Topen call. qids keep the current semantics, but loose some fields that I've added when I wasn't sure yet. To reiterate: a qid is a directory file descriptor plus an optional path. If path is empty, the qid refers to the directory, otherwise to that file in the current directory, c.f. openat(3). This makes implementing Topen easier: for instance, if fid1 and fid2 are backed by the same qid, a Topen on fid1 doesn't need to alter fid1->qid, and so fid2 is still fine. The reference counting on qids ensures that we end up closing all the directories fd.

if a fid was opened for i/o can't be used for twalk

amongst other things, walk now correctly uses fds for each step, so we're not limited by PATH_MAX for the whole walk, but only for the single path component.