From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 23:18:13 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEF84106566B; Wed, 10 Mar 2010 23:18:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-12.mx.aerioconnect.net [216.240.47.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAF78FC14; Wed, 10 Mar 2010 23:18:13 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o2ANICaA015437; Wed, 10 Mar 2010 15:18:12 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id A5CBD2D6018; Wed, 10 Mar 2010 15:18:11 -0800 (PST) Message-ID: <4B9828B2.2010903@elischer.org> Date: Wed, 10 Mar 2010 15:18:10 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Chris St Denis References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org> <4B981FE5.5090905@smartt.com> In-Reply-To: <4B981FE5.5090905@smartt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: n j , freebsd-ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFIREWALL_FORWARD X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 23:18:13 -0000 Chris St Denis wrote: > Julian Elischer wrote: >> n j wrote: >>> Hello, >>> >>> although this has probably been asked before, could anyone point me to >>> some relevant information about why fwd/forward requires kernel >>> recompile, i.e. it's not been made a kernel module? This prevents me >>> from using freebsd-update and forces me to upgrade from source which - >>> even though we all like and love building from source, ofcourse :) - >>> is quite more complicated than the binary upgrade. >>> >>> Thanks, >> >> because when I first committed it I knew that as it broke some >> expected behaviour and added some instructions to the path for >> all incoming and outgoing packets, that if I didn't make it >> an option, I would never be allowed to commit it.. >> >> since then the same reasons have continued.. >> it adds several tests, not all of which are cheap, >> to the packet path. >> >> We could make is dependent on some sysctl >> or something to take out the most expensive tests.. >> but we really need to look at the overall picture of 'extensions' >> and whether there is a general way to handle them. > Is there some reason why it can't just be made a loadable module? > A loadable module requires a coherent piece of code to implement the functionality, that can be put into the module. This option scatters tiny snippets of code throughout the exisitng TCP/UDP/IP/ipfw code.