On Wed, May 15, 2013 at 04:24:04PM +0300, Tomasz Bursztyka wrote:
[...]
> >>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?
I didn't mention the kernel is involved this.
You can have a dispatcher like:
static const struct {
const char *name;
void (*parse)(struct nft_rule_expr_iter *iter)
} netlink_parsers[] = {
[...]
{ .name = "nat", .parse = netlink_parse_nat },
};
the .parse callback gets an iterator to obtain the current expression
and munch more of them if required (will be useful for the payload
case).
Then, the netlink_parse_nat will route the nft_rule_expr object to the
corresponding libxt extension.
> >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.
OK, let's revisit this once you hit limitations.
--
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
