Darren Reed <darr...@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
