Date: Sun, 2 Oct 2005 20:51:57 +0200 From: Max Laier <max@love2party.net> To: freebsd-pf@freebsd.org Subject: Re: pf kernel module(s) Message-ID: <200510022052.08240.max@love2party.net> In-Reply-To: <20051002151642.GC76606@comp.chem.msu.su> References: <20051002151642.GC76606@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Yar, On Sunday 02 October 2005 17:16, Yar Tikhiy wrote: > While making an rc.d script for pfsync as I had promised here, I > noticed that pf.ko didn't include support for pfsync. Closer study > revealed that it would be better to split pf.ko in separate modules > for pf itself, pflog, and pfsync. The reason is as follows. > > As MODULES_WITH_WORLD are about to depart for /dev/null soon, modules > should not rely on the opt_*.h files they create with their Makefiles > now: The configuration is to be obtained from the opt_*.h files in > the kernel build directory. Therefore it will not be possible to > include pflog or pfsync functionality in pf.ko unless it is in the > main kernel file, too, which is ridiculous. OTOH, having separate > pflog.ko and pfsync.ko would allow for the modules to be built > irrespective of the current kernel configuration. > > If the separation is not possible now, the pf.ko module should > include all the functionality irrespective of the DEV_PF, DEV_PFLOG, > or DEV_PFSYNC values found in opt_pf.h. As a matter of fact, a > modern FreeBSD device driver should rarely use DEV_FOO values in > its code because the inclusion of the driver source files in the > build process is the major sign of the driver being enabled, and > device instances should be created dynamically. Alas, OpenBSD > code doesn't seem to follow this trend, so I'd consider setting > NPFLOG and NPFSYNC to 1 statically if possible. There is one big issue with PFSYNC as a module. pfsync needs to register a kernel level multicast protocol. This is not (yet) possible at runtime, but needs to happen statically. So in order to use pfsync you need a pfsync enabled kernel - and can just build in pfsync alltogether. All this makes a pfsync.ko pretty useless. The story for pflog is simply me reasoning that people don't usually want a firewall without logging. And if we know whether or not we have to log at compile time we can save (at least) one pointer deref per packet (and a lot of hook-in/hook-out logic as well). I am open to any improvement of the situation, just wanted to get out the reasoning so you don't have to find out the hard way. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDQCxYXyyEoT62BG0RAuJ+AJ9GzcWJ50saYTYXrl2AoQlrIN40iwCeP4vC 46jnNe1aiL9oulO3vfPsiB4= =TFJr -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510022052.08240.max>