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