David Miller <da...@davemloft.net> wrote: > From: Daniel Borkmann <dan...@iogearbox.net> > Date: Mon, 19 Feb 2018 13:03:17 +0100 > > > Thought was that it would be more suitable to push all the complexity of > > such translation into user space which brings couple of additional > > advantages > > as well: the translation can become very complex and thus it would contain > > all of it behind syscall boundary where natural path of loading programs > > would go via verifier. Given the tool would reside in user space, it would > > also allow to ease development and testing can happen w/o recompiling the > > kernel. It would allow for all the clang sanitizers to run there and for > > having a comprehensive test suite to verify and dry test translations > > against > > traffic test patterns (e.g. bpf infra would provide possibilities on this > > w/o complex setup). Given normal user mode helpers make this rather painful > > since they need to be shipped as extra package by the various distros, the > > idea was that the module loader back end could treat umh similarly as kernel > > modules and hook them in through request_module() approach while still > > operating out of user space. In any case, I could image this approach might > > be interesting and useful in general also for other subsystems requiring > > umh in one way or another. > > Yes, this is a very powerful new facility. > > It also means that the scope of developers who can contribute and work > on the translater is much larger.
How so? Translator is in userspace in nftables case too?
