Darren Reed <darr...@netbsd.org> wrote: > >> 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. > > If libpcap/bpf goes down the path of having "BPF_COP" as part of the > instruction > set but not defining any functions then how does libpcap use it? Or not?
The patch extends the pcap syntax with a keyword. As a library, libpcap merely provides a way for a user to invoke the coprocessor. > Is it better to think of BPF_COP as being a "vendor private" instruction? > Does having a "vendor private" instruction allow for better compatibility > with hardware vendors that produce hardware based packet sniffers? > > The thought here is that BPF_COP suggests that the vendor private thing > should be a coprocessor but if the instruction is just BPF_PRIVATE then it > allows the vendor to do with it whatever they wish, without imposing any > expectations. What is "vendor private"? It does not really matter how you label it. 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. > > 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. > > Which speaks to BPF needing new instructions or a new instruction set > that can > handle those tasks. Not really. It is more of a political issue rather than a technological. Reaching a consensus amongst different communities is just more difficult, regardless of the technical details. -- Mindaugas _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
