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

Reply via email to