remote device access

[David Hogan dhog@plan9.cs.su.oz.au]

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