From panda!genrad!decvax!decwrl!pyramid!hplabs!tektronix!tekcrl!toddb Thu Jan 23 09:54:18 EST 1986 Article: 2243 of net.sources Relay-Version: version B 2.10.2 9/3/84; site teddy.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tekcrl.UUCP Path: teddy!panda!genrad!decvax!decwrl!pyramid!hplabs!tektronix!tekcrl!toddb >From: toddb@tekcrl.UUCP (Todd Brunhoff) Newsgroups: net.sources.bugs,net.unix-wizards,net.sources Subject: Bug fixes for RFS Message-ID: <478@tekcrl.UUCP> Date: 21 Jan 86 21:55:43 GMT Date-Received: 23 Jan 86 01:28:03 GMT Reply-To: toddb@tekcrl.UUCP (Todd Brunhoff) Organization: Tektronix, Beaverton OR Lines: 93 Xref: teddy net.sources.bugs:617 net.unix-wizards:6420 net.sources:2243 Many have installed RFS and tell me that they are satisfied. As anyone would, I am grateful that I could contribute something useful. Please send comments or fixes to me. I will repost as appropriate. There are two very serious bugs in the distribution. What follows is fixes plus my response to a couple of good questions. -- #1 -------------------------------------------------------------- An oversight in making the diffs. If you try to exec a program on a remote system, the system crashes with a ``panic: iput''. You need to fix the end of execve so that it looks like: bad: if (bp) brelse(bp); if (bno) rmfree(argmap, (long)ctod(clrnd((int) btoc(NCARGS))), bno); #ifdef REMOTEFS if (remote < 0) #endif REMOTEFS iput(ip); } It appears that 4.3 does not need this because it does a if (ip) iput(ip); which accomplishes the same thing. -- #2 -------------------------------------------------------------- In rmt_io.c change line 77 so that sleep() has the right number of arguments: sleep((caddr_t)&rp->r_sock, PZERO+1); -- comments ------------------------------------------------------------- Ken Lalonde writes: >The /sys/remote code gets lots of complaints from lint: >lack of casts: ((char *)0, (caddr_t)), unused variables, >lack of (void)s. None of this affects the generated code, >but it's nice to keep the kernel lint-free. Very true. >Shouldn't rmtioctl() and rmtselect() return an error, rather >than 0? Here is how I remember it: the remoteops structure (which holds the reference to rmtioctl() and rmtselect() is purely for the sake of the select() system call. I.e. select() calls the selscan() which calls the select routine via (*fp->f_ops->fo_select)(fp, flag) Which always returns 0. It appears that this should really return a 1 so that a select on a remote file descriptor always succeeds. But maybe not. I would appreciate it if you would investigate further. As for the ioctl, there is a rmt_ioctl() (not rmtioctl) in rmt_syscall2.c which returns the error because it is what is called by remote_startup(), etc. >It seems to me the idea of a generic mount point isn't >worth the trouble (extra code in the kernel and server, >a new syscall, the "pwd" problem). A script to mount >each host, run at boot time, does the job just as well. In your environment (a few big machines), I agree completely. But I have two however's, however. First, I made very sure that very little code that has to do with generic mount is in the way of the main flow of code. Second, in an environment of 2 VAX and 100 workstations, it is indispensable. ------------------------------------------------------------------ D Gwyn writes: >I applaud the contribution of RFS (which should be given some >other name to avoid confusion with AT&T's "RFS"), but I take >issue with the claim that one does not want "find / -print" >to cross over to remote file systems as it traverses the >directory. To the contrary, that is the whole point of RFS >transparency. There are some good examples (such as grepping >for "rnj" in /n/*/etc/passwd) in a Bell Labs paper published >one or two USENIXes ago. I admit that ``grep "rnj" /n/*/etc/passwd'' is desirable, but in general, it is the exception to the rule. And in fact, if you make that the rule, it becomes impossible to find files that are only on your machine. How does AT&T's version do it? I think that the /n node in the example is roughly equivalent to the generic mount point in RFS; if this was more completely implemented, I would think that it should be able to accomplish about the same thing. As it is, the best you can do is with csh: grep "rnj" /{vax1,vax2,vax3}/etc/passwd or with the generic mount point. grep "rnj" /net/{vax1,vax2,vax3}/etc/passwd ------------------------------------------------------------------ Todd Brunhoff toddb%crl@tektronix.csnet {ucbvax,decvax}!tektronix!toddb