Date: Fri, 29 May 2009 20:13:27 -0700 From: Steven Schlansker <scs@eecs.berkeley.edu> To: freebsd-questions@freebsd.org Subject: Re: pfsync in GENERIC? Message-ID: <9DCE53EA-E680-48C3-BF7F-A5AAC656EB6D@eecs.berkeley.edu> In-Reply-To: <gvpuhd$7aj$1@ger.gmane.org> References: <89C182FE-81B9-474E-84EA-FBB6F68C4E75@eecs.berkeley.edu> <200905292001.02072.mel.flynn%2Bfbsd.questions@mailing.thruhere.net> <C113D42F-C628-4E91-8AFE-BD2556502AC7@EECS.Berkeley.EDU> <200905292244.37398.mel.flynn%2Bfbsd.questions@mailing.thruhere.net> <B8CF04BE-3165-4BD5-A3C6-8D68742CDA26@EECS.Berkeley.EDU> <gvpuhd$7aj$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DCE53EA-E680-48C3-BF7F-A5AAC656EB6D>