Steven Schlansker wrote:
> Hm. I was actually under the impression that you wouldn't gain much
> by compiling your own kernel (except for maybe some disk space). Is
> that not the case? Is there a strong reason to compile your own
> kernel for "production" machines? The discussion online is not
> conclusive (then again I'll probably just get contradictory opinions
> again here!)
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.
> 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.
> 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.
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.
...my measly little $.02
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"