tdd@convex.cl.msu.edu (Thomas D. Davis) (08/29/90)
I'm having an awful time trying to so something seemingly simple. I've exported my /dev directory from one Sun (say machine A) and mounted it on another Sun (machine B). I can see all the entries in this directory from B, but when I try to perform I/O on a character device (eg. ttya) it just plain doesn't work. I can see from the NFS spec that this will have an "rdev" of NFCHR (as opposed to NFREG) but I don't see why that would make any difference. -- Tom Davis | The above statement shall be construed, Network Software Services | interpreted, and governed by me alone. Michigan State University | EMail: tdd@convex.cl.msu.edu
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (08/29/90)
Quoth tdd@convex.cl.msu.edu (Thomas D. Davis) (in <1990Aug28.212809.23872@msuinfo.cl.msu.edu>): #I'm having an awful time trying to so something seemingly simple. I've #exported my /dev directory from one Sun (say machine A) and mounted it #on another Sun (machine B). I can see all the entries in this directory #from B, but when I try to perform I/O on a character device (eg. ttya) #it just plain doesn't work. I can see from the NFS spec that this will #have an "rdev" of NFCHR (as opposed to NFREG) but I don't see why that #would make any difference. When you access a file which is a character or block special device, the semantics are identical whether the file is local or remote: the major/minor pair are retrieved and interpreted within your local kernel by using the major number as an index into the appropriate device switch (cdevsw or bdevsw). In other words, if /dev/ttya is a character special file with maj/min [21,1] your local kernel must include a valid entry in entry #21 of the cdevsw, and that device driver should be able to understand a minor device number 1. If the driver is, say, a cartridge tape driver, the net result is that the operation (read, write, whatever) is going to be applied to cartridge tape unit #1 on your local system. It doesn't matter where the special file exists: the effect is strictly local. It sounds like you expect to be able to access the corresponding special file on the server. NFS doesn't support this, for a number of reasons. First, you *have* to be able to provide the semantics which I just described in order to make diskless nodes work. After all, if you have a diskless workstation its /dev is going to be stored on the server, and you really want /dev/fb to refer to your local frame buffer and not that on the server :-) So if you want to access remote devices you need a different model. Secondly, given the Unix interface to special files (basically open/close/read/write/ioctl) there is no way to create an over-the-wire protocol to handle them in an architecture independent manner. Open/close/read/write are ok, but what about ioctl? Take a look at the binary representations of various ioctls. There is no "correct" way to XDR generic ioctl arguments and replies, nor is there any standard binary representation of the ioctl's themselves: there is no guarantee that TIOMGET on my system has the same representation on yours. There are two possible solutions - standardize everything (yeah, right!) or adopt a portable representation. Neither is feasible in the short term. [Actually, the real answer is to adopt an architecture such as Plan 9, but that has other drawbacks.] -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- *** "Now is no time to speculate or hypothecate, but rather a time *** *** for action, or at least not a time to rule it out, though not *** *** necessarily a time to rule it in, either." - George Bush ***
prc@erbe.se (Robert Claeson) (08/30/90)
In a recent article tdd@convex.cl.msu.edu (Thomas D. Davis) writes: >I'm having an awful time trying to so something seemingly simple. I've >exported my /dev directory from one Sun (say machine A) and mounted it >on another Sun (machine B). I can see all the entries in this directory >from B, but when I try to perform I/O on a character device (eg. ttya) >it just plain doesn't work. For things like these, you would need AT&T's RFS (Remote File Sharing), which preserves all UNIX file semantics over the network. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer (ask him).
guy@auspex.auspex.com (Guy Harris) (09/02/90)
>For things like these, you would need AT&T's RFS (Remote File Sharing), >which preserves all UNIX file semantics over the network. Well, except for "ioctl()"s (and except for "mmap()" of devices - S5R4's version of the RFS protocol will, I think, support "mmap()" of files over the network, but there's a bit of work involved in letting machine A map machine B's frame buffer into its address space :-)). S5R3 definitely doesn't canonicalize "ioctl()" arguments; S5R4 has a mechanism for doing so on STREAMS devices - this could, I think, be done for non-STREAMS devices as well, but I don't think it was.