pfsync in GENERIC?

[Steven Schlansker]

On May 29, 2009, at 5:29 PM, Michael Powell wrote:

> Steven Schlansker wrote:
>
> [snip]
>
> 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.

Yeah, that's basically how I felt as well.  However as to the  
"something unneeded causing a problem" I must say I've never had a  
GENERIC kernel fail due to some unneeded device driver, but I've  
definitely had a custom built kernel fail because of some tunable or  
driver I misconfigured!
>
>
>
>> 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.

That makes perfect sense and answers my question.  I hadn't realized  
that there were alternatives to pf and that people still actively used  
them.

>
>
>> 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.

There is no PR apparently; I shall file one.

>
>
> 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.

I like to try to be one of the more useful retards on the internet ;)   
I'm hopeful that getting it to work at least for the unicast setup  
shouldn't be too hard; granted I haven't perused the code yet...