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.
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
