remote device access

[serge@euler.Berkeley.EDU serge@euler.Berkeley.EDU]

(``I say we hang this srege heretic in effigy!''
 ``To heck with it!  Let's hang him right here!''
 :-)

>the notation was invented as an expedient way to address drivers before
>the name space was established, a function it serves well.

But don't you need a file system / name space before you can run, e.g.

	% cat /lib/namespac
	# root
	mount -a #s/boot /
	...

i.e. where do (/bin/)mount and /lib/namespac come from to begin with?
(For that matter, where does #s come from?  :-)

>i prefer the notation to be distinct.  when what's going on is
>fundamentally nasty, it is polite to say so; hence #c.

My concern is that it pretends to be in file system space, while it
really isn't (you can't ls/cp/rm/etc. it).  At least with Unix'
major/minor device numbers, even though they are ``magic'', they're not 
intrusive/interfering with naming.  E.g. in Plan9, I can't have a file
called #c (there goes emacs ... hm ... :-).  This is pretty much
like DOS' con[:] et al, which I think we can all agree isn't elegant.
:-)

I believe VSTa has a /namer file system, so that, e.g. you can find out
the name of the root file system via

	cat /namer/fs/root

Perhaps if some ``magic'' (ugh) at boot time made all the drivers
accessible in /drivers in a similar way (akin to the way that ``/''
is mounted)?

>if one were to attach all drivers to the name space automatically [...]
>one would go against the grain of plan 9, where what is in the name
>space is what is needed rather than all that's available.  besides,
>this latter form implies an attach has been done, a semantically heavy
>operation best left until the driver is really needed.

Actually, I wasn't suggesting attaching/binding all the drivers, merely
making them visible via the normal file system name space / operations.
Or removing them from the name space entirely.  :-)