Re: BPF_COP support for libpcap

[Mindaugas Rasiukevicius <rmind () noxt eu>]

Darren Reed <darrenr () 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.
>
> So?
>
> 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.

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