In some email I received from Atsushi Onoe, sie wrote:
> > Why do we need bpf_tap, bpf_mtap and bpf_mtap2 ?
> 
> > That said, your proposal for bpf_mtap2() was:
> > 
> > void bpf_mtap2(caddr_t bpf, caddr_t hdr, int hdrlen, struct mbuf *m);
> 
> bpf_tap and bpf_mtap can be integrated or even defined by macro to use
> bpf_mtap2.
[...]
> Perhaps, add extra space for link header at using mbuf in drivers
> if possible, and use of M_PREPEND() could be better for performance.
> Unlike old BSD mbuf functions, our M_PREPEND() can be used also for
> mbuf clusters.

I thought about doing that, I just wasn't sure where the right place to
do that was or if it would be a good idea, in general.

> Obviously, it cannot be applied for if_loop, but I'm not sure IDS want
> to see loopback interface.

No, you are right.  But for ppp0 or tun0, I can see being used by IDS.

> How about proposing such manner in use of bpf_mtap if you really think
> the performance for bpf is the issue?

Most of the ideas I've had I've already floated in this discussion and
I'm not sure anything I have had to say has been a winning argument but
nevertheless those ideas have been explored and the problem given more
consideration which is not a bad thing.

Except for one last thing, I have been thinking about.  In the case of
DLT_NULL, it almost makes no sense for there to be anything prior to the
mbuf (there is no data) and unless pcap generates code that does check
to see if something == DLT_NULL, maybe it can be skipped?  To do this
would require passing an offset through to bpf_filter() and all load/store
operations to an offset would have the passed offset subtracted.  That
just may be another silly idea tho :)

Anyway, if you've spent some time working on your ideas, I'd like to see
what the patches make the code look like (URL would be fine.)

Cheers,
Darren