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 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...
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to