On Thu, 4 Dec 2003, Devon H.O'Dell wrote:
This is obviously the most logical explanation. There's a good bit of
questioning for PFIL_HOOKS to be enabled in generic to allow ipf to be
loaded as a module as well. If this is the case, we'll have two
firewalls that have their hooks compiled in by default allowing for them
both to be loaded as modules. (Is this still scheduled for 5.2?)
But at this point, there's no way to allow one to turn the IPFW hooks *off*. Is there a reason for this?
Would it be beneficial (or possible) to hook ipfw into pfil(9)? This way, we could allow the modules to be loaded by default for both and also allow for the total absence of both in the kernel. Sorry if I've missed discussions on this and am being redundant.
Sam Leffler has done a substantial amount of work to push all of the
various "hacks"" (features?) behind PFIL_HOOKS, and I anticipate we'll
ship PFIL_HOOKS enabled in GENERIC in 5.3 and use it to plug in most of
these services. This also means packages like IPFilter and PF will work
"out of the box" without a kernel recompile, not to mention offering
substantial architectural cleanup.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Senior Research Scientist, McAfee Research
This is great news and definitely something I am interesting in contributing to. Sam: how can I help with this?
Kind regards,
Devon H. O'Dell
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
