Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!uudell!bigtex!texsun!newstop!exodus!appserv!slovax.Eng.Sun.COM!lm From: lm@slovax.Eng.Sun.COM (Larry McVoy) Newsgroups: comp.unix.internals Subject: Re: (was slashes, now NFS devices) Message-ID: <468@appserv.Eng.Sun.COM> Date: 26 Feb 91 05:35:33 GMT References: <15236@smoke.brl.mil> <123382@uunet.UU.NET> <1991Feb22.141910.17013@decuac.dec.com> <14363@ulysses.att.com> Sender: news@appserv.Eng.Sun.COM Reply-To: lm@slovax.Eng.Sun.COM (Larry McVoy) Organization: Sun Microsystems, Mt. View, CA. Lines: 23 bzs@world.std.com (Barry Shein) writes: A whole bunch of stuff about remote devices, with which I agree entirely and then says: >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. We have rdump/rrestore. I know of no plans to extend NFS to deal with devices. Like someone (Barry?) said: it stands for networked *file* system, not networked devices. Nobody, including RFS, has ever come up with networked devices in any sort of general fashion. Before the neophytes start whining that it is easy, consider ioctl's. There are zillions of them, all magic numbers, system calls, really, specific to each device. The only reason that RFS works is that it "knows" about the server. This means that the server had better have the same byte order, have the same kernel, etc. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com Brought to you by Super Global Mega Corp .com