Re: mountd, rpc.lockd and rpc.statd patches for testing

Andrey Simonenko wrote:
> On Mon, May 30, 2011 at 04:56:02PM -0400, Rick Macklem wrote:
> > Hi,
> >
> > I have patches for the mountd, rpc.statd and rpc.lockd daemons
> > that are meant to keep them from failing when a dynamically
> > selected port# is not available for some combination of
> >   udp,tcp X ipv4,ipv6
> >
> > If anyone would like to test these patches, they can be found
> > at:
> >    http://people.freebsd.org/~rmacklem/mountd.patch
> >                                        statd.patch
> >                                        lockd.patch
> >
> > Although I think I got them correct, they are rather big and ugly.
> >
> 
> I have checked this update for mountd in 10-CURRENT and has two
> questions:
> 
> 1. What is the sense to try to use the same port number for all
> supported netconfigs if specific port number is not given in
> a command line option?
> 
Well, there was a discussion of this on one of the mailing lists
at the time. I started with a much simpler patch that didn't try and
make all 4 <udp/tcp, ip4/ip6> combinations use the same port#, but
others felt that was important. (Something about tracking what port#
were in use, but I can't quite recall. If you want to know the reasoning,
look for the thread that would have been shortly before the commit.)

> 2. What is the sense of specifying specific IP addresses for mountd
> and
> similar RPC programs that do not have predefined port numbers?
> 
I'm not sure what you are asking here? (Are you referring to the "-h"
command line option?)

> 
> One comment for netconfig related functions usage. Each setnetconfig()
> call allocates memory and depending on implementation can use other
> resources, so endnetconfig() should be called before reusing netconfig
> handle.
> _
Ok, I'll take a look someday. Since it happens a finite number of times,
any leak should be bounded and, as such, shouldn't cause serious problems.
However, I wasn't aware of the above and it should be fixed.

rick

> -------------------------------------------
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"