From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <23ADFC2E-B18A-46DA-A1C1-B14EA6B29EB1@mac.com> From: Gary Wright To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 13:54:32 -0400 References: Subject: Re: [9fans] 9p2010 Topicbox-Message-UUID: f168bec8-ead4-11e9-9d60-3106f5b1d025 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).