On 13 July 2017 at 20:22, Phil Sutter <phil@xxxxxx> wrote: > There are so many different cases, I actually started drawing flow > diagrams (can't remember when I did that last time). In addition to what > we discussed already, I realized that via 'nft -f', I can make multiple > changes to even different sets within a single transaction - this > requires dealing with cached half-open ranges everywhere, not just in > NEWGEN callback. Another trap is 'nft flush set': The elements are > reported in reverse order. Anyway, I have something that seems to work > but needs quite some cleanup before I dare to publish it. :) > In an ideal world, we would detect these 'flush x' calls and print just that, instead of every single object being deleted. I.e. flush ruleset --> monitor prints 'flush ruleset' instead of every single object in the ruleset being deleted. But at this point, I think that going this way would increase complexity in this code a lot. Better fix by now the broken things we have. > I should probably look into ways to write tests for this to get all the > cases covered. > Indeed, but if your --echo functionality is going to use the very same code path, then we should wait for it, because testing the monitor thing is not that easy (async output). The --echo output is sync with the command you call, so you can simply check the output. Once the code is in place, this is a good task for one of our students/interns in GSoC-like programs. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
