If all issues raised by Daniel are addresed: Acked-by: Hagen Paul Pfeifer <ha...@jauu.net>
But ... >Future work: > >0. seccomp > >1. add extended BPF JIT for x86_64 > >2. add inband old/new demux and extended BPF verifier, so that new programs > can be loaded through old sk_attach_filter() and > sk_unattached_filter_create() > interfaces > >3. tracing filters systemtap-like with extended BPF > >4. OVS with extended BPF > >5. nftables with extended BPF ... this is shit (not your fault). (Jitted) BPF envolved into a direction which is just not the right way to do it. You try to fix things, bypass architectural shortcomings of BPF, perf issues because and so on. The right direction is to write a new general purpose in-kernel interpreter from scratch. Capability layers should provide an compatible API for BPF and seccomp. You have the knowledge to do exactly this, you nearly already did this - you should start this undertake! -- Hagen Paul Pfeifer -- 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/
