Date: Fri, 5 Jun 1998 12:28:11 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: dyson@FreeBSD.ORG, nate@mt.sri.com (Nate Williams) Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Documenting sysctls (was: Re: kernfs/procfs questions...) Message-ID: <9806051228.ZM15866@beatrice.rutgers.edu> In-Reply-To: "John S. Dyson" <dyson@FreeBSD.ORG> "Re: kernfs/procfs questions..." (Jun 4, 7:05pm) References: <199806050005.TAA00859@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 4, 7:05pm, John S. Dyson (possibly) wrote: > Nate Williams said: > > > > Do I have permission to start removing sysctl's that aren't > > > > documented/used? > > > > > > > No, in fact, I specifcally suggest that if you do, then you'll > > > be obstructing progress on the project. > > > > I specifically suggest that undocumented sysctls are *NOT* progress. > > (BTW, what exactly is specifically suggest supposed to mean. Is it like > > 'strong suggest', or 'strongly feel'?) > > > I suggest that you are welcome to document the sysctl's. Since you > seem to be able to choose which ones are valid, and which ones are > not, you can certainly document them. Please don't decline my > request, because I'll have to end up fixing any of your breakage, > and it is terribly wasteful of both of our time. > > BTW, please don't waste my time. If you want sysctl better documented, > then there is a nice project for you!!! I'll even feed answers > to your questions for you to fill in the fields. Umm... while everyone's talking about documenting sysctls, would somebody mind explaining exactly what proxyall does? From reading over the source code, I _think_ that this is what happens, but I'm not sure: A. If the machine receives an arp request for an IP address that's not one of its, and B. the arp request isn't from one of its interfaces, and C. there isn't an arp table entry saying it's supposed to broadcast something specific for an arp request for that IP address, and D. the proxyall sysctl is on, and E. it knows how to route to the IP address in question, and F. the route doesn't go out the same interface the arp request was received on, then G. it replies with the ethernet address of the interface the arp request was received on as the ethernet address to send stuff for that IP address to. If this is indeed the case, then putting documentation to this effect somewhere would be nice. With this and IP Filter's transparent forwarding capability, it appears possible to use a FreeBSD box as a L2-filtering-bridge, which would be quite nice. Thanks, -Allen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9806051228.ZM15866>