Commits
- Commit:
7bafb2fd590c5e1b2ebf342df0c431ff4ca6b74c
- From:
- Omar Polo <op@omarpolo.com>
- Date:
ftp: issue slightly smaller requests to please u9fs
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.
- Commit:
aa495dd96b6a7bfeda47c5bab4682e3e28fb030e
- From:
- Omar Polo <op@omarpolo.com>
- Date:
annotate hex values for 9p message types
it's a bit easier to debug hexdumps now
- Commit:
344d2bade53f42086e3ddc0054a7a82b2a2efe9a
- From:
- Omar Polo <op@omarpolo.com>
- Date:
9pclib: fix qid serialization
twstat was serializing the qid in the wrong order. While here, add a
comment before the qid definition too.
- Commit:
9029ac6f3c1fa3e42c6fa231f8a45ed05d68b61e
- From:
- Omar Polo <op@omarpolo.com>
- Date:
wstat: missing read for size
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.
- Commit:
4cce062e124368e36a756d13097e57f2f2c33a39
- From:
- Omar Polo <op@omarpolo.com>
- Date:
move struct np_stat to kami.h
- Commit:
fb1a36c0a6028fb69d26ed62cafee077a0c345ce
- From:
- Omar Polo <op@omarpolo.com>
- Date:
restructure project and switch build system
use by default the OpenBSD mk infrastructure to build and test all the
kamid components.