remote device access

[forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk]

>>escape/special case, more uniformity, etc. :-) You could even
>>conceivably bind /cpu/dri/xxx to /dev/xxx to access cpu server's drivers?

you can already do that (several ways).  for example,
when the cpu command connects a terminal to a cpu server,
it exports the devices in that window to the
cpu process on the cpu server, which imports them into its name space
and rebinds them on /dev/bitblt, etc., where the graphics programs find them.
X11-style network graphics thus requires no code at all that's specific
to network graphics: it simply reuses the existing code supporting import/export
of any file system.

i frequently use my terminal's floppy on the CPU server to take work home.
on plan 9, i don't need GNU-style remote-tape hacks to every conceivable
program.  furthermore, i can export at various levels: i can export
the floppy device (allowing me to tar to it, or perhaps run dossrv remotely),
or i can export dossrv's view of it (making the DOS files available
remotely), or even do both at the same time.  similarly, i can export
a CDROM device, or 9660srv's view of it. 

of course, import/export/bind works the other way round,
so that a terminal can get the cpu server's files, including devices.
for example, plan 9 machines here can import the /dev/rtctime file on one of our cpu servers
that is updated by the Rugby time service, replacing its own /dev/rtctime
or /dev/time if desired.  another cpu server acts as the Usenet news server,
using a local disc containing /n/kfs/news.  any client (cpu server or terminal)
that wants to read news simply imports that.

improvements can perhaps be made in the way a name space
is built, but the functionality you suggest
is already available with little fuss (and no code bloat).