u9fs like to return "i/o count too large" on reads/writes that exceeds msize - 24. seems arbiratry, as in theory we should be able to issue a Tread/Twrite for msize - (HEADERSIZE + 4) = msize - 13. Don't know where the other eleven bits come from. To conclude the rant: even if a client issues a Tread/write too large, why don't just return a value smaller than requested? It's explicitly documented in the plan9 manpage for Tread.

it's a bit easier to debug hexdumps now

twstat was serializing the qid in the wrong order. While here, add a comment before the qid definition too.

9p stat message have a leading 2 bytes long size field. It's meant to simplify the parsing, because while reading the contents of a directory it's necessary to know how much long an entry is, so the length field is present even in the Rstat reply and in the Twstat input. Previously we didn't consume that bit and thus mis-read all of the following fields.

use by default the OpenBSD mk infrastructure to build and test all the kamid components.