remote device access

remote device access

[serge]

(``Oh, no, not this surge guy again.''  :-)

>>You could even conceivably bind /cpu/dri/xxx to /dev/xxx to access
>>cpu server's drivers? 

>you can already do that (several ways).

Yes, I know that.  I should have been more clear: I meant, e.g. if your
kernel doesn't have the driver you need (e.g. you just hooked up a
CD-ROM to your machine), you can import it from another machine and use
it on your machine.  This would differ from importing the binding of the
driver, e.g. /dev/cdrom, from another machine, since then you would be
using _its_ driver with _its_ CD-ROM, rather than with _your_ CD-ROM.

This would be similar to, e.g. QNX, where device drivers are processes.
E.g. you would network mount another machine's disk, run the driver/process 
from this network drive and use it to access your local device.

The idea is to make things even more uniform and remove further special
cases.  (I.e. the ``#name'' notation is Plan9's analog to major/minor
device numbers / mknod of Unix, which is ``magic''.)

``It has been our observation that when objects behave like files,
practically any program can use them without modification.'' (sic?)
--Ritchie, V8 Streams paper in '85 USENIX

remote device access

[David]

>>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).

I dunno, ls '#c' works for me!

>E.g. in Plan9, I can't have a file
>called #c (there goes emacs ... hm ... :-).

Well, actually you can, but you have to be careful how you reference it.  ie,
echo foo >'./#c'

remote device access

[David]

>>the machine architectures are often not the same, so in general a
>>precompiled driver isn't much use off its own machine.
>
>You mean the whole world isn't a VAX ... er, I mean a PeeCee?  :-)
>
>This wouldn't be any different from, e.g. a PC client/terminal getting
>its (PC) binaries from a, say, SGI server (c.f. /386/bin/rc), etc.
>Wouldn't it?

I'm still not sure exactly what you are suggesting.  Plan 9 does get
away with having much fewer drivers in its kernel.  For instance,
there is no tape driver in the kernel, instead you run "scuzz" (ie
/386/bin/scuzz), a user-mode program which talks to the raw scsi
device.  Similarly, there is no code in the kernel for interpretting
the contents of iso9660 CD-ROMs, all this is done by a user level server. Contrast this with BSD UNIX or Linux, which have to have all of this
stuff compiled into the kernel.

Maybe your question is something along the lines of "why can't
all the drivers be user-mode programs?".  There are some very good
reasons for not doing this.  For starters, supposing all of your
files are obtained via the ethernet.  Then you are obviously not
going to get very far unless there is an ethernet driver compiled
into your kernel.  Similarly if you boot off a scsi disk, then you
have to have a scsi driver in your kernel.

The other constraint is efficiency.  Plan 9 doesn't have "loadable
kernel modules" or any near equivalent; if you want to add functionality
to the system from user-mode, then the new stuff runs in user-mode.
The problem with running a device driver like this is that every time
you get an interrupt, you have to take the transition from kernel
mode to user mode.  (And on a pc, every I/O port access is another
system call on top of this).  This would be completely unnaceptable
for a lot of devices, which require timely response to interrupts,
and would render other devices painfully slow.

Maybe you are asking why Plan 9 doesn't have loadable kernel modules.
These would actually add a lot of complexity to the system.  Plan 9
does such a good job without them, that adding them would be (IMNSHO)
a big mistake.  And from what I've heard of Brazil, it has even less
stuff built into the kernel.  Rather than working out some way of
making the kernel extensible via some special mechanism, the Plan 9
paradigm is to extend it in the way that it's always been extensible,
ie user-level file servers.

Going back to your earlier example: what if I don't have the CD-ROM
driver installed, and I want to read a CD-ROM?  The SCSI CD-ROM driver
is one driver which could be provided by a user-mode program.  In the
previous release, booting with the CD-ROM as the root filesystem was
the main way of getting started, but this is no longer true.  So I
guess it's still a kernel device mainly for historical reasons (and
possibly for efficiency reasons too).  The great thing about SCSI
is that all you really need in the kernel is the SCSI driver itself,
which handles all the low level device stuff, and you can then access
any kind of SCSI device with the apropriate user-mode program.

If your CD-ROM drive is of the PC Soundblaster (ie non-SCSI) variety,
then you really do want the driver to be in the kernel, or else it
will be too slow.  I have actually managed to play audio CD's on
such a device using a user-mode program, however.  (Since the CD-ROM
drive does all the real work, there are no efficiency concerns).

remote device access

[serge]

(``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.  :-)

remote device access

[serge]

>the machine architectures are often not the same, so in general a
>precompiled driver isn't much use off its own machine.

You mean the whole world isn't a VAX ... er, I mean a PeeCee?  :-)

This wouldn't be any different from, e.g. a PC client/terminal getting
its (PC) binaries from a, say, SGI server (c.f. /386/bin/rc), etc.
Wouldn't it?

remote device access

[rob]

getting rid of the '#c' stuff is only hard because it's a widely used convention.
the notation was invented as an expedient way to address drivers before the
name space was established, a function it serves well.  it was never claimed
to be clean or elegant.  other ways may be cleaner or more elegant, but i think
	/driver/c
or some such is neither.  this is a syntactic fudge that pretends to hide the real
problem, which is that there is no name space at the dawn of time.  pretending
to have one by introducing such a notation tells a lie.  looking at it one way,
who walks these names?  if you access them by walk at all, you have a name
space and you've reduced down to a previously unsolved problem.  if you have
another access mechanism, well, you have another access mechanism and it
will not generalize.  when a mechanism doesn't generalize, i prefer the notation
to be distinct.  when what's going on is fundamentally nasty, it is polite to say
so; hence #c.

on the other hand, if one
were to attach all drivers to the name space automatically, avoiding the need for
a (public, at least) #c, building up /driver or /dev or whatever, 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.

remote device access

[forsyth]

>>Yes, I know that.  I should have been more clear: I meant, e.g. if your
>>kernel doesn't have the driver you need (e.g. you just hooked up a
>>CD-ROM to your machine), you can import it from another machine and use
>>it on your machine.  This would differ from importing the binding of the
>>driver, e.g. /dev/cdrom, from another machine, since then you would be
>>using _its_ driver with _its_ CD-ROM, rather than with _your_ CD-ROM.

oh i see.  the machine architectures are often not the same,
so in general a precompiled driver isn't much use off its own machine.

remote device access

[Boyd]

i think getting rid of the #c stuff is pretty hard.

how does this stuff work in brazil (rob, phil)?

remote device access

[forsyth]

>>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).