pfsync in GENERIC?
scs at eecs.berkeley.edu
Sat May 30 03:13:35 UTC 2009
On May 29, 2009, at 5:29 PM, Michael Powell wrote:
> Steven Schlansker wrote:
> A custom kernel can free up a little RAM, and maybe boot a little
> 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
> 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
>> 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
> choose from. Since theoretically(?) each should be usable as modules
> 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
>> Anyway, if I have further questions about pfsync in particular I
>> I'll go ask -pf. I may have some free time coming up; maybe I'll
>> 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
>> 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
> reports for more details. At some point a dev may take care of the
> 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
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...
More information about the freebsd-questions