(was slashes, now NFS devices)

[Barry Shein]

From: ekrell at ulysses.att.com (Eduardo Krell) [responding to me]

>>Obviously they should be interpreted
>>relative to the local host only.
>
>Not so obvious to me. After all, the server is probably the only machine
>which can interpret the meaning of that special file in a sensible way.
>By forcing a local interpretation of special files, you lose the ability
>to access remote devices.

And if the server is a different architecture than the client does
that mean that if I run a mounted server binary that the server should
know to run it instead (including properly simulating my window,
shell, I/O [remember that local modem I have], etc environment)?

I realize there are projects out there trying to precisely this sort
of thing, but they don't do it by introducing little mods to NFS.

And what do we do when we get a conflict, for example, who's /dev/kmem
should ps read?

By forcing local interpretation, you maintain some semblance of
sanity.  Your characterization of a server full of wild and wonderful
devices and a client bereft of the same devices is just a particular
view of computing, and not a very modern one actually (take that!)

The server may very well be nothing but a huge box with a bunch of
disks on it and an ethernet port (eg. Epoch, Auspex) while my client
may have all the modems, scanners, printers, 4/8mm tape, CD/ROM, WORM,
mouse, keyboard, vidoeo interface, etc etc etc.

Remote devices are generally accessed via programs, this is made even
more important due to the many clients and one server model. How is
device locking (or implicit queueing) etc supposed to work under your
scheme?

I know, I know, it can all be made to work, and has been made to work,
but not by merely adding a few hacks to NFS.

>If you can access remote files, why can't you access remote devices using
>the same mechanism? Under RFS, special files are interpreted by the server.

RFS? Oh, uh, no comment (I wonder if there's anyone on this list old
enough to remember RFS :-)

One correct answer is, because of the myriad ioctl()'s and so forth
that come along with devices. But I've given ten other reasons in
these notes.

Look, it could be done, but doing it as a simple extension to NFS
is almost certainly *not* the right way to do this.

Oh, who knows, maybe due to market pressure Sun will even add this to
NFS. But I would expect it to be of very limited use (like maybe using
a tape drive in a cooperative environment) until a lot of other issues
are answered.
-- 
        -Barry Shein

Software Tool & Die    | bzs at world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD