From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7f7d37e3f08741687eaa3b7c910e3cf6@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] design clairvoyance & the 9 way From: "Russ Cox" In-Reply-To: <2d47347353bfadb65915218426041e72@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 8 May 2003 12:25:01 -0400 Topicbox-Message-UUID: a4813f12-eacb-11e9-9e20-41e7f4b1d025 A student here at MIT is going to try out something approaching dm's idea. Make the kernel interface 9P instead of the usual file system calls. Have the kernel do proper multiplexing* of the 9P connections rather than rely on exportfs's inexact approximation. Exportfs becomes a system call, like in Inferno but with a precise implementation. Processes that want to do a lot of overlapped I/O can exportfs("/") and then interact with their name space via 9P messages, avoiding the need for lots of slave procs to manage just to run I/O. The kernel drivers would change to deal with 9P explicitly (like the 9P2000 lib9p interface) rather than assume that the call needs to have the reply ready before it returns (like the 9P1 lib9p interface). This will complicate things a little, but opens new doors too. For example, the SCSI driver could easily look at the 9P queue and do disk scheduling or issue multiple SCSI requests at once. It'll be a while before we see how it turns out. Russ [*] By proper I just mean that the message are translated faithfully. Exportfs can't do that exactly since it's constantly rewalking paths and trying to use the system calls to implement the messages.