pfsync in GENERIC?

[Michael Powell]

Steven Schlansker wrote:

[snip]
> 
> Hm.  I was actually under the impression that you wouldn't gain much
> by compiling your own kernel (except for maybe some disk space).  Is
> that not the case?  Is there a strong reason to compile your own
> kernel for "production" machines?  The discussion online is not
> conclusive (then again I'll probably just get contradictory opinions
> again here!)

A custom kernel can free up a little RAM, and maybe boot a little sooner, 
but it won't produce any earth shattering differences. I think most do it to 
'shrink' down and eliminate anything which is not required for a particular 
piece of hardware. It decreases the possibility of something unneeded 
causing a problem, and enhances problem resolution by making the list of 
potential culprits smaller.

 
> I'm just thinking that since pf is included in the base distribution,
> there's enough people that use it that it's worth including.  It seems
> that pfsync would be a negligible addon, and much more attractive due
> to the lack of support for building it as a module.

IIRC, quite a while back IPFW was the default firewall and was included in 
GENERIC by default. With the advent of IPFILTER and PF we now have 3 to 
choose from. Since theoretically(?) each should be usable as modules and 
user freedom/choice are paramount, I believe it was decided to remove any 
default firewall from the GENERIC kernel to enable a user to simply load the 
module of their choice without needing to do a kernel re-compile first. In 
other words, flexibility.
 
> Anyway, if I have further questions about pfsync in particular I guess
> I'll go ask -pf.  I may have some free time coming up; maybe I'll even
> try my hand at hacking on the kernel and see if I can't make it build
> as a module... (would that be a semi-reasonable project for someone
> with light familiarity with kernel coding?  I've coded up Linux kernel
> modules before, but haven't worked in-tree on a "real" OS)
> 

I believe the module situation may be a known entity. Consult the PR bug 
reports for more details. At some point a dev may take care of the situation 
and it will just show up in some future release.

Should you desire to "hack" into it yourself and succeed the devs will 
welcome the patch/diffs for perusal and testing provided you go about it the 
right way. Advancing the state of FreeBSD is always a plus, and I as a user 
salute all those who strive and work towards making FreeBSD a better OS.

...my measly little $.02

-Mike