Hi Pablo,
If I understood this correctly, your approach uses the array of
instructions above as keys to look up for the corresponding parser. In
that case, I'm afraid that this engine won't cover the complexity of
the payload instructions since we'll end up having*a lot* of matching
combinations that will overlap in your tree. You cannot resolve that
ambiguity problem of what parser needs to be invoked without looking
at other information that is contained in the instruction, eg. payload
base and offset.
It already handles overlapping patterns. I decided to go the simplest way:
- you can register as many parser you want for a pattern, of course.
- engine will try as many parser it has for a pattern as long as those
return -1, the one who returns 0 wins (engine tries then to continue on
next expressions, finding other patterns)
- engine follows longest pattern first: so if no parser as won on the
current pattern, engine will start to go backward. (it will try to match
shorter pattern)
Have a look at nft_trans_add_instruction(),
retrieve_nft_trans_instructions() and execute_relevant_instruction() for
insights.
Sure it's definitely not the most optimized but I believe it should be
sufficient for our concerns.
And anyway, the API is good enough so the engine itself can be
transparently improved if necessary.
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
