From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 01:38:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7DFF1065676 for ; Sun, 24 Aug 2008 01:38:19 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 334F98FC0A for ; Sun, 24 Aug 2008 01:38:19 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id A6F9733C57; Sun, 24 Aug 2008 05:38:17 +0400 (MSD) Message-ID: <48B0B813.8010606@localhost.inse.ru> Date: Sun, 24 Aug 2008 05:23:31 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Max Laier References: <48B07DC5.2030203@localhost.inse.ru> <20080823231407.GA76471@onelab2.iet.unipi.it> <48B09ACD.1050600@localhost.inse.ru> <200808240149.56698.max@love2party.net> In-Reply-To: <200808240149.56698.max@love2party.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Luigi Rizzo Subject: Re: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2008 01:38:19 -0000 Max Laier wrote: > On Sunday 24 August 2008 01:18:37 Roman Kurakin wrote: > >> Luigi Rizzo wrote: >> >>> On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: >>> ... >>> >>> >>>>> unless the tools you have in mind already include ip_fw.h (in which >>>>> case the change is harmless and I have no objection), i think it would >>>>> be better to export the value in a sysctl and let the tools fetch it >>>>> from there, so they do not need to include the header. >>>>> >>>> In fact, I am talking about ipfw(8) and natd(8). The first one uses >>>> hard-coded value, the last one >>>> pass rulenumbers to libalias(3) without a check, libalias(3) flushes >>>> >>> ... >>> >>> >>>> IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would >>>> be better to export >>>> this value via sysctl, not compiled in via #include<> for it. The only >>>> >>> because ip_fw.h has a lot of stuff in it which in turn is likely >>> to require more headers to build correctly. This is unnecessary bloat >>> at compile time, and also less practical than the sysctl-based approach >>> because it requires a binary update if the value ever changes. >>> >>> Besides, implementing the sysctl does not require to change the >>> headers (thus saving rebuilds of the objects that depend on it), >>> is one line in one file (ip_fw2.c) in the kernel, and one line to >>> call sysctlbyname() in each of the userland program, which you'd >>> need to change anyways; and because both ipfw(8) and natd(8) already >>> use sysctl/sysctlbyname to read/write other similar values from the >>> kernel, you are more consistent with the existing code and don't >>> even need additional headers. >>> >> Agreed, but including ip_fw.h for natd.c does not require any additional >> headers. >> All that needed looks like already there. >> If some one point me to other utilities that need to be fixed I'll also >> a sysctl for them. >> These two already include enough of netinet includes, so if you not >> strictly against adding >> just one more include for natd, I'll prefer not to add a sysctl by right >> now. >> > > There is no guarantee that the kernel or ipfw module you are running was built > with the installed ip_fw.h or that IPFW_DEFAULT_RULE wasn't defined > differently in the build environment. So a sysctl (or the like) is the *only* > Very strange situation. In such case we have a very buggy code that could be broken by such cases in many places, cause we can't trust even kernel headers. But if you insist I'll do it via sysctl. > correct approach. Please fix it for real and don't just slap band-aid at it. > Nice catch, by the way! > It is bad luck. I always hit problems than I lack of time setting up smth. All problems where they are not expected I mine ;-) Now time to sleep until I didn't catch other problems :-))) rik >> rik >> >> >>> At runtime the sysctl is obviously more expensive than reading a >>> hardwired constant, but still a whole lot cheaper than the subsequent >>> action (adding a rule to the firewall) so one won't notice. >>> >>> cheers >>> luigi >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > >