Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.protocols.nfs
Subject: Re: Novice NFS questions
Message-ID: <1991Mar26.073554.2230@thunder.mcrcim.mcgill.edu>
Date: 26 Mar 91 07:35:54 GMT
References: <945@dri500.dri.nl>
Organization: McGill Research Centre for Intelligent Machines
Lines: 89

In article <945@dri500.dri.nl>, heinhuis@dri.nl (Gustaaf-Jan Heinhuis) writes:
> 	"The objects that can be shared through NFS include any whole
> 	or partial directory tree or file hierarchy-including a single
> 	file.  A machine cannot share a file hierarchy that overlaps
> 	one that is already shared.  Special device files, as well as
> 	ordinary files, can de shared over NFS; however, peripheral
> 	devices such as modems and printers cannot be shared."

> I'd very much like to know what, in this context and in general, is
> meant by "special device files".  I, in my innocence, would say such
> a file represents a device (like a printer), but apparently I'm
> wrong.

You are both right and wrong.  That is to say, you are partially right.

A special device file is something like all those things that clutter
up /dev.  The only thing that is shared is that aspect of it which is
stored in the filesystem, which (aside from things, like permission
bits, which all files have) is the <major,minor> device number pair
(and the bit saying whether it's a block special or character special
device, which is a bit of a fossil).  To this extent, special device
files can be shared.  That is to say:

	server# mkdir /gleep
	server# mknod /gleep/foo c 107 130

(Now, /gleep/foo is a "special device file" on the server.  I'll get to
what this means in a minute.)

	server# exportfs /gleep -o access=client,rw=client

(Using Sun's exportfs syntax for lack of any other accessible to me.
This tells the server that `client' is allowed to nfs-mount /gleep.)

	client# mount server:/gleep /gloop

Now, /gloop/foo is a special device file on the client.  This is the
sense in which they can be shared.

Now, in what sense are they not shared?  To explain this, and to
understand the apparent contradiction in your quote from the manual, we
need to delve into just what a special device file does.

The utility of a device special file is that it allows access to a
device.  This may seem obvious, but the reason I mention is that the
crucial question to ask is *how* it does this.  How is the connection
made between the string "/dev/tty03" and the third line on that serial
line card in the machine?

Well, part of that we know already.  /dev/tty03 is a special device
file with <major,minor> numbers <22,3> (say).  Where do we go from
there?  We go into the kernel.  In the code that implements the open()
syscall, we find a check for special device files.  In the case of a
character special device file (block special files are identical for
the purposes of this discussion), the major number (22 in my example)
is used as an index into a table (traditionally called `cdevsw') which
is compiled into the kernel.  This table entry contains pointers to a
handful of functions which are responsible for interfacing between the
software and the hardware.  (These functions are collectively referred
to as a "device driver".)  One of these is the open function; open
calls this.  (What happens to the minor number?  That's one of the
things passed to the driver's open routine.)  All access to the device
goes through these function pointers.  When you write to it, for
example, it ends up calling the driver's write routine.

Now, enter NFS.  Suppose the client gets the /gloop/foo special device
via NFS.  What happens when it's accessed?  Well, the kernel will
notice that it's a character special device <107,130> and go looking in
cdevsw for entry 107, then call the open routine and tell it to open
minor device 130.  -- but wait a minute.  This all happens on the
client.  It's the *client's* cdevsw that's used and it's the *client's*
driver (if any) that gets called and it's the *client's* hardware that
the driver speaks to.  Not the server's.

Thus, you see, while special device files may be shared, the hardware
they refer to isn't, simply because the device file doesn't really
carry the connection to the hardware; all it carries is a pointer into
the kernel data structures and thence to the hardware.  So what
hardware is accessed depends on whose kernel handles the access
attempt.

I hope I haven't been too obfuscatory here; if there's anything still
unclear about it, feel free to send me mail.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu