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
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
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
default firewall from the GENERIC kernel to enable a user to simply
module of their choice without needing to do a kernel re-compile
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
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...
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"