From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <70b1be7bf1a870538ecd7c40d8b83810@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] A proposal regarding # in bind From: "Russ Cox" In-Reply-To: <200302261332.NAA02827@dircon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Wed, 26 Feb 2003 09:14:00 -0500 Topicbox-Message-UUID: 72fde634-eacb-11e9-9e20-41e7f4b1d025 Here's a different proposal, also just an idea rather than a complete proposal, but perhaps worth pursuing. Suppose you recentered the kernel around 9P, building a muxer that wasn't process-based like devmnt's currently is. Then you could have two system calls int exportfs(void); int exportdev(void); that return file descriptors. The file descriptor returned by exportfs gives you a private 9P conversation operating on your current name space. You could post it or do anything else with it, just like the similar call in inferno. Exportdev() would return a 9P file descriptor but for the devices. You mount it to get the device tree. (Perhaps mounting with a spec like "#l0" gets you a specific device; maybe the spec should be a path in the device tree like "/ether/0".) Rfork(RFNODEV) (nee RFNOMNT) would cause exportdev to fail, preventing access to devices not in the name space. The underlying kernel interface to drivers would have to change -- they'd all need to process 9P messages, so probably there would be a wrapper that let them be implemented in the style they currently are. But some devices (for example, the disk devices) might choose to deal in 9P directly so that they can access the request queue and perhaps behave more efficiently. If you're not careful there might be problems with data getting copied more often than it needs to. For example right now I believe that a raw write to the screen image via /dev/draw copies from the user space buffer directly into video memory. It would be unfortunate if we lost that (though loadimage does its own user-space copy first anyway). Russ