In some email I received from Charles M. Hannum, they wrote:
> 
>    I guess if you wanted, you could allow for two "programs" to be
>    resident in memory (for BPF) for both input and output, on each
>    interface (total of 8 for a dual interface "firewall" host) and
>    switch between the two.
> 
> No; what I'm `getting at' is the ability to install a new filter while
> the old one is still active.  This could mean having two BPF filters
> in the kernel for a brief period, but unless you have separate
> processes switching all the filters at once (which I'd expect to be an
> extremely rare occurance), this still only means having one extra
> filter in the kernel at once.  And even if by some random chance all
> the filters are being switched at once ... so what?

Sorry, that is what I meant; I'm just not up on all the right terms to
use when talking about BPF.

Anyway, if you're dead set on using BPF and sticking by that, then there's
not much I can do/say (I concede it is a superior filter, for the purpose
of filtering packets).  I'm not totally convinced of it being as useful for
more complex (?) situations involving packet filtering in a firewall-type
situation where it is possible for demands other than just pure filtering
of packets arise.  Nor do I think that BPF should be "hacked" to provide
these features but if you or someone else is willing to hack something up
to produce the required functionality with BPF, good luck to you/them.

I would add, at this point, that if NetBSD is going to (strongly) stick
by BPF then it look closely at incorporating libpcap into the release.
I'm sure Charles is familiar with it, and from what I've seen of it so
far, it will make further use of BPF easier/more encouraging.

Cheers,
darren