On Wed, Mar 12, 2014 at 3:16 PM, Cong Wang <cw...@twopensource.com> wrote: > (Sorry for jumping into this thread late.) > > On Mon, Mar 10, 2014 at 9:41 PM, Alexei Starovoitov <a...@plumgrid.com> wrote: >> >> 3. tracing filters systemtap-like with extended BPF >> >> 4. OVS with extended BPF >> >> 5. nftables with extended BPF > > If you plan to use extended BPF out of networking, does > it make sense to make it independent of networking? > That is, rename those sk_*() APIs?
well, v1 and v2 series already demonstrate how ebpf can be used for tracing. That's why in v1 series they were under kernel/ dir, but since it's a natural bpf extension that reuses a lot of bpf pieces, it makes sense for the whole thing be in net/core/filter.c and in linux/filter.h I believe that was a consensus in v2-v3 series. I don't want to rename the whole thing once again. Also seccomp is not networking, but it already uses bpf and after these patches ebpf. So net/core/filter.c location is fine. >> >> +int bpf_ext_enable __read_mostly; >> + > > This could be converted to a jump label, no? yes, but it's not in critical path, so no need. Thank you for taking a look! Even late feedback is always appreciated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/