On Tue, 6 Aug 2002, Atsushi Onoe wrote:

> > > >  1) A driver supporting more than one DLT will call bpf with a new
> > > >     procedure, bpfattach_multidlt, passing bpfattach_multidlt a mask
> > > >     describing the DLTs the driver supports.
> > >
> > > Since the number of supported DLTs for a driver would be limited,
> > > multiple calls to bpfattach_dlt() may be accepted.
> > > This would help to implement streight forward implementation which splits
> > > bpf_if for each DLT.
> >
> > But do we want multiple bpf_if's? My original idea was there would be one
> > bpf, just it could hand back different packet types.
>
> Hmm, I've found my previous implementation.  I admit it is something like
> ad hoc, but it works well and it has complete compatibility.

That code is missing one of the key points:

+#if NBPFILTER > 0
+               if (ic->ic_rawbpf)
+                       bpf_mtap(ic->ic_rawbpf, m0);
+#endif

One of the main points of the effort was that when using the new
interface, drivers would by default hand NOTHING to bpf. bpf has to call
the driver to request packets of type X or type Y. Thus you only make
packets IFF there is a consumer.

So if I understand your code right, (ic->ic_rawbpf) is a necessary but not
sufficient condition to hand the packet off to bpf_mtap. The bpf system
would have had to ask for that packet type too. So something like:

if ((ic->ic_rawbpf) && (ic->ic_raw_bpfcount))
	bpf_mtap(ic->ic_rawbpf, m0);

and ic->ic_raw_bpfcount is incremented when bpf asks for that packet type,
and decrememnted when it says it's done.

"Asking" would be done by an ioctl.

This step is important as otherwise we are going to destroy performance.
We're looking at adding 802.11, a driver specific type, and (I think) a
common 802.11+stuff type. With the original 802.3, that's four packet
types. Unless there's a consumer for each of these different frame types,
I think we should NOT make them. :-)

That also was one of the reasons for wanting to break backwards
compatability (*). By attaching the interface with the new call, you are
informing the bpf layer that you will only make packets when it has asked
you to. That's a big behavioral difference, so a different API seems
appropriate.

(*) Of course old drivers still would work as they did.

Take care,

Bill