[pooka%netbsd.org@localhost: CVS commit: src/sys]

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

----- Forwarded message from Antti Kantee <pooka%netbsd.org@localhost> -----

Module Name:    src
Committed By:   pooka
Date:           Tue Jan 19 22:08:18 UTC 2010

Modified Files:
        [snip]
        src/sys/net: bpf.c bpf.h if_arcsubr.c if_atmsubr.c if_bridge.c
            if_ecosubr.c if_etherip.c if_ethersubr.c if_faith.c if_fddisubr.c
            if_gif.c if_gre.c if_hippisubr.c if_ieee1394subr.c if_loop.c
            if_ppp.c if_pppoe.c if_sl.c if_srt.c if_stf.c if_strip.c if_tap.c
            if_tokensubr.c if_tun.c if_vlan.c ppp_tty.c

Log Message:
Redefine bpf linkage through an always present op vector, i.e.
#if NBPFILTER is no longer required in the client.  This change
doesn't yet add support for loading bpf as a module, since drivers
can register before bpf is attached.  However, callers of bpf can
now be modularized.

----- End forwarded message -----

I disagree with this change, at least the part about using a function
vector. This adds the overhead on an indirect call for no good reason to
a common code path for every single network packet, if there is a BPF
listener. That happens as soon as the interface is configured by DHCP.

The same benefit of being able to modularize BPF could be obtained by
pushing down the indirect calls into the actual functions. That could at
some future point also be optimised by binary patching. This only
matters of course, if someone actually wants to make BPF a module, which
I am not too sure about given the constrains already mentioned.

So please change this back to use normal function calls. It might be a
good time to change bpf_mtap and friends to be simple macros that
include the if (ifp->if_bpf) check, but that's more a cosmetic question.

Joerg