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...
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
