[tcpdump-workers] BPF_COP support for libpcap
rmind at noxt.eu
Wed Jun 10 17:48:27 EDT 2015
Darren Reed <darrenr at netbsd.org> wrote:
> > What is "vendor private"? It does not really matter how you label it.
> Yes, it does.
> By defining an instruction to be "something" there is an expectation that
> it will be used for that "something."
Your "something" is rather vague. BPF_COP is used by NetBSD, standalone
NPF on Linux, and it is supported by standalone bpfjit. It provides a
great flexibility for other use cases.
> > It is worth to note that we might want to support multiple coprocessors.
> > Very much like in MIPS - for memory management, FPU and various hardware
> > accelerators - we might have a standardised coprocessor along with the
> > custom ones.
> Doesn't it give a vendor more flexibility to have an instruction that
> isreserved for them to use however they wish rather than to have it
> defined as "something"?
It is exactly what COP provides for the user. The BPF coprocessor API is
quite clearly described and implemented in the NetBSD kernel. If libpcap
community would like to have a full COP support in the libpcap interpreter,
then I am happy to backport it. However, just the "cop" keyword itself is
a useful feature: users can compile programs using the pcap-filter syntax
*and* custom mechanisms implemented by their coprocessor.
> The limitations of BPF are not confined to what has been developed for
> NetBSD with the BPF_COP addon. As an example, it is not possible to do
> a native 64bit operation with BPF as it is today - that's not a political
> issue, that's technical. The issue of there being no advanced primitives
> is another - the solution used by NetBSD with BPF_COP is just one way of
> dealing with that problem and it is a workaround to being able to do the
> right thing within the scope of BPF instructions and since the
> instruction set is limited so people try to avoid using new instructions.
Of course not, because it solves a different problem (specifically, a way
to extend BPF and support complex/external operations). It is not solving
the inherent limitations of classic BPF instruction set (32-bit operations,
limited instruction space, short jumps, etc). Linux eBPF, as an example,
is something what attempts to solve some of these problems.
> The only time it gets "political" (if you will) is when someone says their
> modification should be "the solution", when it doesn't really solve the
> problem of shortcomings in the instruction set and its definition.
You have not provided a single reasonable argument so far. The reason why
I am not keen to see various specialised instructions is that they pollute
the instruction space which, in classic BPF, is already quite limited.
Moreover, it is a pollution with CISC-like instructions when we currently
have a quite neat RISC-like set. You know, there is a reason why BPF_MSH
is called "a hack" in bpf(4) manual page. :)
Having said that, I think is worth to consider new instructions for IPv6
header walking or other functionality (or limitations of BPF byte-code in
general), but this discussion is quite orthogonal to the BPF_COP issue.
More information about the tcpdump-workers