Re: BPF_COP support for libpcap

[Mindaugas Rasiukevicius <rmind () noxt eu>]

Michael Richardson <mcr () sandelman ca> wrote:
> Mindaugas Rasiukevicius <rmind () noxt eu> wrote:
>     > A while ago NetBSD gained support for BPF_COP instruction, see [1]
>     > for more details.  However, now there are use cases of it outside
>     > the NetBSD kernel, e.g. standalone NPF packet filter running as a
>     > program on Linux. Hence I would like to add the support for the
>     > BPF_COP instruction to the pcap_compile() and pcap_dump() of the
>     > libpcap library.
>
> It seems like a good thing to have to evolve BPF forward, particularly
> in light of more and more complex 802.1q and "metro-ethernet" ring
> layer-2 formats, and walking IPv6 header chains.
>
> It seems that we really wind up needing a registry of co-processor
> function indexes... which begin to seem like new instructions in some
> sense. Perhaps the difference is that they are better defined, and more
> dynamic.

Well, the patch just provides the capability to invoke the coprocessor.
The benefit of BPF_COP approach is that the vendors can implement their
custom coprocessor and use through libpcap/tcpdump without polluting the
instruction space.  I think the RISC-like coprocessor approach (think of
MIPS) is both clean and powerful compared to adding complex instructions.

It would be good to have some general purpose coprocessor (for walking
IPv6 header chain and other operations), but that would probably be
difficult to agree and standardise amongst the vendors.

Speaking of evolving BPF, I would love to see Linux eBPF support (except
the new instructions).  That is a separate discussion though.

> > - As there are users who want to pcap_compile() an expression with
> > BPF_COP
> >  on Linux, can we expose BPF_COP or make it otherwise available for the
> >  systems where this instruction would not be in the net/bpf.h header?
>
> instructions currently live in pcap/bpf.h in the libpcap directory.

Will move it to the pcap/bpf.h file.  The question is whether #ifndef
approach on BPF_COP is fine?  Also, any comment on opt_stmt() change
in optimize.c?  It is somewhat convoluted code and I might have missed
some edge case.

If the patch looks fine, should I make a github pullup request?

-- 
Mindaugas
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers