Bug fixes for RFS

[Todd Brunhoff]

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 at tektronix.csnet
			{ucbvax,decvax}!tektronix!toddb