On Apr 23, 2009, at 12:26 PM, erik quanstrom wrote:
with 9p2000, if you want to do a Tread, it's pretty clear that
one needs to read(2); traditiona syscalls map directly to 9p.
It seems to me that the syscall interface is by design different than
the 9p2000 api:
- most syscalls map to a sequence of 9p2000 messages (allocate a new
fid, walk to the named resource, open/stat/remove)
- open files are represented by file descriptors, not 9p2000 fids
- file descriptors map to fids in a n -> 1 relationship
- file descriptors maintain a current offset
- other than fids associated with file descriptors, the only other fid
associated with a process is the current working directory (i.e. you
can't cache the result of a Twalk other than via the current working
directory)
- there is no direct access to Twalk
- the semantics of a process namespace is a non-trivial multiplexing
of several 9p2000 namespaces
I was reading through the source of exportfs the other day and it
struck me that there was quite a bit of work involved in mapping
incoming 9p2000 messages into syscalls within the process namespace
(e.g., fids vs file descriptors, qid clashes).
