On Fri, Dec 20, 2002 at 12:27:59PM +1100, Darren Reed wrote the words in effect of: > Well someone has blown my cover from developers and has asked here > what I was trying to be more surrepticious about! > > In some email I received from Sam Leffler, sie wrote: > > > A teeny-weeny issue I would like to discuss, is that we make the pfil(9) > > > hooks code default in 5.0, and remove the kernel option; this is because > > > it creates problems when PFIL_HOOKS is not in the (e.g. GENERIC) kernel, > > > and someone tries to load the ipfilter kernel module (ipl.ko). [1] > > > > > > I have discussed this with Darren, but would just like to make it > > > public, so it can be discussed by the release engineers etc. I > > > apologize but I do not have patches for this. > > > > > > > Enabling PFIL_HOOKS changes various code paths. Doing this so late in the > > release cycle is a bad idea. I also recall that there is a performance > > penalty (at least in the bridge code) for having this enabled. > > There are callouts in both the IPv{4,6} paths for input and output with > PFIL_HOOKS and also bridging. > > PFIL_HOOKS is 1 .c file and 1 .h file and a very small amount of code. > Also, given its generic nature, I'd hope that ipfw* could eventually > move to use it for intercepting packets along the above code paths. > > The bloat factor from including it in the base kernel should be very > small and perhaps the impact of the code being active in those packet > paths close to immeasurable (I hope.) > > > Both issues make it seem like it should stay an option for 5.0. > > I agree with this.
Maybe we should put in the release notes, that: "PFIL_HOOKS is required for IPFILTER" -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message