Re: enabling bridge_ipf

[Greg Troxel <gdt%lexort.com@localhost>]

Maxime Villard <max%m00nbsd.net@localhost> writes:

>> The only reason not to would be if it created a lot more code and made
>> the kernel bigger, or some worry about a few instructions per packet in
>> bridging.  Surely it's just a tiny overhead, and it doesn't really make
>> sense for bridges to be special vs other interfaces.  (If someone wants
>> to compile out PFIL_HOOKS, this should go too.)

I went and read the code.  Hard-enabling BRIDGE_IPF does bring in a
bunch of lines of code, but it doesn't seem that big.   So I don't have
a problem with this.

> PFIL_HOOKS is IPF-specific, not related to bridges, and hard-enabled as far
> as I can tell (ie, not an option).

I don't follow "IPF-specific" as it seems to be an abstract interface to
an arbitrary packet filter.  But agreed that I can find no evidence of
PFIL_HOOKS being optional - I think I am remembering long ago.

>> So my only request is to do a test compile with PFIL off.

> There is no PFIL option available. "pfil" is a small set of functions which
> are unconditionally part of the kernel.

Didn't realize that was non-optional; request withdrawn.