[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: enabling bridge_ipf
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.
Main Index |
Thread Index |