Hi Pablo,
Why not, it's a design preference. I liked the idea extension don't
mess up with the rule and only provides its expression list.
it's less code on libnftables on your idea at least.
We have to trust our iptables extensions.
What extra sanity checking are you going to make anyway if the
extension puzzles with this internal expr_list?
What do you mean?
Return 0/-1 instead of pointer/NULL is same.
As I said I am fine with your proposal in addition that it requires less
code in libnftables.
Now on the reverse way, we don't know at all to which extension the
expression list belongs to, so which translation function to call.
Currently the only way I see it is to loop on all extensions until
one returns successfully.
You need some dispatcher code that interprets the nft_expr and routes
it to the right iptables extension. So you will need also one .c file
per expression in the kernel, e.g. nft_nat.c, that performs this
dispatching / routing to the right extension.
You lost me. Why kernel is involved here?
Probably checking netlink_delinearize.c in nft can provide your some
ideas.
Yes, and I actually use netlink_linearize.c to help for translation.
We should take care of the position in the expression list as well,
and here I see we will need some more functions from libnftables.
You have the expression iterator already.
I believe it won't be sufficient. Let's see.
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
