(was slashes, now NFS devices)

[Eduardo Krell]

In article <FWP1.91Feb23160240 at Jester.CC.MsState.Edu> fwp1 at CC.MsState.Edu (Frank Peters) writes:

>You ignore (or aren't aware of) two important differences between RFS
>and NFS that make this impractical.

No, I'm well aware of the difference between RFS and NFS. RFS is a distributed
Unix filesystem and guarantees Unix semantics on remote files.

>   The concept of a file
>   system entry that points to a device by magic major and minor codes
>   is very OS specific.  While that concept is by no means unique to
>   UNIX it is far from universal and implemented differently wherever
>   it is found.

I don't see how this implies that the client should interpret the
special file. What if the client is a PC running DOS?
And to Unix users, NFS is not stateless. What is rpc.lockd used for?

>No, I think special files must be treated like any binary data.  If I
>mount my sparc executables on a MIPS box those files are meaningless
>data.

Well, if you're cross compiling on the MIPS for the sparc, then they
might not be meaningless. I agree with you that special files should
be treated like any binary file, that is, opening that file on the
client or the server should yield the same result. What happens when
you read a binary file on the client? Do you get a different byte stream?

>If I choose to write a UNIX device file interface emulator for
>VMS or DOS I should be able to pass it the special file data for local
>interpretation.

I don't understand. What if the special file is associated with a device
on the server like a tape or CD-ROM player or whatever? What good would
it do for you to have a "device file interface emulator" on the client
when the only way to access that device is through the device driver in
the server?
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell at ulysses.att.com