Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: (was slashes, now NFS devices) Message-ID: Date: 24 Feb 91 00:36:30 GMT References: <15236@smoke.brl.mil> <123382@uunet.UU.NET> <1991Feb22.141910.17013@decuac.dec.com> <14363@ulysses.att.com> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 62 In-Reply-To: ekrell@ulysses.att.com's message of 23 Feb 91 20:30:48 GMT From: ekrell@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@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD Brought to you by Super Global Mega Corp .com