Re: [9fans] A proposal regarding # in bind

["Russ Cox" <rsc@plan9.bell-labs.com>]

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