Date: Wed, 10 Mar 2010 14:40:37 -0800 From: Chris St Denis <chris@smartt.com> To: Julian Elischer <julian@elischer.org> Cc: n j <nino80@gmail.com>, FreeBSD Net <freebsd-net@freebsd.org>, freebsd-ipfw@freebsd.org Subject: Re: IPFIREWALL_FORWARD Message-ID: <4B981FE5.5090905@smartt.com> In-Reply-To: <4B97E412.1050506@elischer.org> References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B981FE5.5090905>