On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote: > Darren Reed <darr...@netbsd.org> wrote: >> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: >>> Darren Reed <darr...@netbsd.org> wrote: >>>>> >>>>> You do not have to use it. >>>> >>>> I get no choice - it is in the kernel by default. >>>> >>> >>> There is no default coprocessor. Here is your choice: do not call >>> bpf_set_cop(9) and those instructions will effectively be NOPs. >> >> Anyone with the required privileges to run tcpdump can set this >> coprocessor. > > You got it wrong. Sorry if I was not clear, I will try to clarify > it again.
Rather than try explaining it across an email thread, maybe the design should be presented fully and accompany a problem description. >> At present it is impossible for there to be an infinite loop because >> it always branches/jumps forward, thus preventing looping behaviour. >> >> It is this very strictness that makes BPF work and worthwhile. >> >> Without that, it may as well be Java or some other byte code language. > > What kind of strictness are you talking about? Previously you were > talking about security, now about the capability of the BPF byte-code. The strictness that makes it impossible for there to be infinite loops (for example.) That strictness also imparts security. > The coprocessor support provides offloading capability. Yes, it does... > If your point was that we should not consider improvements and conserve > the instruction set from 80s, then we simply disagree. :) No, improvements in BPF are required for IPv6, e.g. http://permalink.gmane.org/gmane.network.tcpdump.devel/5141 >> Ok, I'll un-contradict myself: >> it shouldn't be possible for BPF to consist of mneumonics that are >> function calls that work on the packet rather than operations on the >> registers/memory. If I implied that this was ok then I was wrong. > > Can you provide a justification for this? Because then BPF ceases to be a language that can be verified for security, reliability and performance purposes. >> Is it trying to deal with a limitation/problem in npf? > > Not at all. This is to avoid code duplication. It is BPF which has a > limitation and BPF_COP is a clean way (design wise) to address it. Maybe you should start this proposal properly with a problem description and how this solves it. There isn't nearly enough information in what has been presented to properly understand what has been proposed. Darren _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
