Topen implemented 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.

initialize to -1 fid' fd

update qid and fid structs + docs 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.

don't allow duplicating a fid already opened for I/O if a fid was opened for i/o can't be used for twalk

fmt

bit of refactoring 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.

lower the priority of some logs

disable DEBUG_PACKETS

compute path/vers/type in twalk' wqid

fix the Rwalk serialization

move hexdump to utils

drop useless check

typo! nwname should be checked, not nwqid

improve qid implementation qid now aren't *always* associated with a fd. They are associated with a path instead. The may be associated with a fd if the client preared a fid for I/O. At Tattach time we don't necessarily open the directory, we just stat it. Same during Twalk.

fix comment