From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 22:40:29 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 EF1631065672 for ; Wed, 10 Mar 2010 22:40:29 +0000 (UTC) (envelope-from chris@smartt.com) Received: from mailout3.smartt.com (mailout3.smartt.com [69.67.187.28]) by mx1.freebsd.org (Postfix) with ESMTP id D60398FC25 for ; Wed, 10 Mar 2010 22:40:29 +0000 (UTC) Received: from [69.31.174.220] (unknown [69.31.174.220]) by mailout3.smartt.com (Postfix) with ESMTPA id 01F7810E45E; Wed, 10 Mar 2010 14:41:03 -0800 (PST) Message-ID: <4B981FE5.5090905@smartt.com> Date: Wed, 10 Mar 2010 14:40:37 -0800 From: Chris St Denis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Julian Elischer References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org> In-Reply-To: <4B97E412.1050506@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: n j , FreeBSD Net , freebsd-ipfw@freebsd.org 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 22:40:30 -0000 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? -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses"