Hi Pablo,
Could you recheck in detail patches 3/16 and 4/16?
If there is no flaws in the translation engine, we might just go for
it at it is.
I'm not convinced that this approach is the way to go. In the payload
case, the number of instruction tuples will explode, and you will have
to iterate many times to find the corresponding parser.
There are many ways to reduce drastically such lookup process, current
implementation is just here to prove it works.
I have actually some code for that, by extending the instruction
declaration with extra infos, it kills looping. Not finished though.
(have also a solution for not pre-loading all extensions, btw)
Actually NAT is probably the worst example. I should have implemented 2
or 3 totally different other extensions.
Because nat exists as its own expression in nftables, so indeed it's
really easy to pick it up in an expression list.
if (expr == "nat") parse_nat();
But it's not going to be that simple with complex set of different
expressions representing one extension.
Of course it's can still work with programmatic way but it's going to be
really annoying in maintenance, entangled code, bug prone etc...
Since every time you will support a new extension, code will need to change.
With my approach: no code change needed anymore, just declaring the
right instruction which is very trivial.
Anyway, I really think we have to start by converting nft to ipt
command state in one single patch, as your patches 11-13 do, we need
it for whatever approach we decide to follow. If you don't have time
to make that rebase, I'll try to find some spare time to work on it.
Let me know.
I can find time.
Tomasz
--
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
