The return of nftables

Posted Aug 21, 2013 22:01 UTC (Wed) by ncm (guest, #165)
In reply to: The return of nftables by johill
Parent article: The return of nftables

I guess the question, then, is why not add this stuff to bpf? In the best case, it would be that bpf proved not to be a good enough foundation. The way these things go, it could as well be that improving bpf was less exciting than replacing it.

The return of nftables

Posted Aug 21, 2013 23:50 UTC (Wed) by wahern (subscriber, #37304) [Link] (2 responses)

The original author was well aware of BPF, and used it as the model. But clearly he thought it preferable to start writing code from scratch, and the project has already surpassed BPF in functionality. Plus, he who writes the code gets the say-so. (Also, the BPF virtual machine is actually quit tiny, and the line between re-writing it and copy+pasting it is rather thin.)

So, it's kind of a moot point. It would be one thing if the project stalled before surpassing BPF in functionality. Then we could all jeer "I told you so". But this doesn't seem to be one of those occasions. nftables seemed to stall simply because too many people are comfortable with iptables, and are heavily invested in the arcane common-line syntax. And those who aren't can shift to using PF on OpenBSD or FreeBSD. Plus NetBSD has NPF, now, which is pretty cool.

The return of nftables

Posted Aug 22, 2013 16:57 UTC (Thu) by intgr (subscriber, #39733) [Link] (1 responses)

> Also, the BPF virtual machine is actually quit tiny, and the line between re-writing it and copy+pasting it is rather thin

One of the advantages of BPF is that Linux already has a working BPF JIT compiler for many architectures (x86, ARM, SPARC, POWER and S/390). This is a non-trivial amount of code.

The return of nftables

Posted Aug 22, 2013 18:25 UTC (Thu) by raven667 (subscriber, #5198) [Link]

Could this work the other way around, consolidating on nftables as the backend for BPF processing in the kernel rather than maintaining two similar systems.