Nftables reaches 1.0
Nftables reaches 1.0
Posted Aug 28, 2021 15:41 UTC (Sat) by hailfinger (subscriber, #76962)In reply to: Nftables reaches 1.0 by jkingweb
Parent article: Nftables reaches 1.0
- The syntax is nice once you get used to it and I think most of it is more easily readable due to the structure
- The documentation was incomplete, especially for NAT
- If the documentation says that two ways to specify a rule are equivalent you should verify that instead of blindly rewriting working rules
- Concatenations are cool, but rarely work
- Order within in a single rule matters sometimes
- Combining the same rule from "table ip nat" and "table ip6 nat" into "table inet nat" only works in some cases
- If your kernel and the nftables userspace are not the same age you will run into problems, so either upgrade both or none, this may be different now that 1.0 is released
- Kernel 5.10 is roughly where most of the interesting functions start working if your userspace is new enough and nftables 0.9.6 (Buster Backports) is similarly a point where things start working better
- On Debian Buster without backports the whole thing is really painful, it's manageable with backports
- Priorities as keywords (introduced in 0.9.6) instead of priorities as numbers helps a lot with readability compared to older versions
- Error messages exist, but in netfilter 0.9.6 (from 2020) they were as helpful as gcc error messages ("error: expected ‘asm’ or ‘__attribute__’" instead of "missing semicolon") from the era before llvm, they are a bit better now
Overall, I think nftables has a nice future ahead and I'm looking forward to testing nftables 1.0.
Posted Aug 28, 2021 20:25 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Ahah, that's actually a coincidence. GCC error messages for C were bad mostly due to the usage of yacc for the parser. When the parser was rewritten as recursive decent in 2004 by Joseph Myers that laid the foundation for improving error recovery. They then finally improved when GCC developers including myself got fed up of a few particularly egregious cases[1][2].
But competition with llvm wasn't particularly involved. In fact for C++ (which used recursive descent since before clang was started) error message quality has always been comparable to clang.
More recently (and long after I had stopped working on GCC), David Malcolm did a huge amount of work on caret diagnostics, where GCC's front ends were indeed lagging behind. But that's a different story.
[1] https://gcc.gnu.org/legacy-ml/gcc-patches/2010-10/msg0261...
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2010-11/msg0180...
Posted Aug 28, 2021 21:24 UTC (Sat)
by Paf (subscriber, #91811)
[Link] (1 responses)
Posted Aug 30, 2021 13:22 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link]
In C, the problem was abysmal error recovery, causing dozens of cascaded errors for a single missing semicolon or fat-fingered type name (such as "intt" or "unsgined char"). With a recursive descent parser it's relatively easy and maintainable to add heuristics that look ahead and insert missing tokens or fix things up as necessary. For example if you see two consecutive unknown identifiers, it's likely that the first is a misspelled type and the second is a variable name. With some luck, that will remove a lot of errors involving that variable, because the compiler now knows about it and treats it as declared.
Nftables reaches 1.0
Nftables reaches 1.0
Nftables reaches 1.0