On Fri, Jul 13, 2012 at 3:40 PM, Chris Cappuccio <[email protected]> wrote: > Andres Perera [[email protected]] wrote: >> for clients (processes) that need to do trivial filtering, e.g., >> tcpdump 'ether multicast and not broadcast', it's an overhaul for >> nothing >> >> the placement of the filtering stack in the kernel is completely >> irrelevant to "how simple" it will end up. if you come up with a >> sbin/bpfd it will still have to do locking between clients, and >> present a higher level subset to be of any use >> >> i don't expect *every* application to manage the rx/tx rings directly, >> reinject when they're done >> >> to actual uses of userland packet capture, this whole situation >> resembles "wayland is not an x replacement, it just does compositing" >> > > situation? it's just a tool. what makes you think the primary users will be > the same ones who want to use BPF? >
you did! you explicitly said that it would be advantageous for programs looking to perform analysis on captured packets. for those programs, it turns out the placement of the filter doesn't matter
