From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 27 Apr 1995 04:29:06 -0400 From: forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk Subject: remote device access Topicbox-Message-UUID: 0e2c1ff8-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19950427082906.AJWj51cGIJbfUyNCKsnC3lZ10OZJCYr-gQEtVDnM5SQ@z> >>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).