hi Anders, 2016-10-21 12:16 GMT+08:00 Anders K. Pedersen | Cohaesio <akp@xxxxxxxxxxxx>: >> >> But after I think it carefully, I think the NFTA_RT_FAMILY attr >> seems useless, we can combine these four files nft_rt.c, >> nft_rt_ipv4.c, nft_rt_ipv6.c and nft_rt_inet.c into a single one >> file nft_rt.c. > > My implementation is based on the suggestion from Pablo at > http://marc.info/?l=netfilter-devel&m=147438531502686&w=4 . Yes, but after I carefully read your codes, I find that the related implementation code about the family attr is not very good. Without the family attr, we can still make everything well, and the codes will become more clean and straightforward. As a summary: For ip family, nexthop must be ipv4 For ip6 family, nexthop must be ipv6 For inet family, nexthop can be selected by pkt->pf and we can add an implict rule that the user cannot do wrong operation. So I think the NFTA_RT_FAMILY attr is almost useless. > >> For eval, we can use pkt->pf to decide which rt or rt6 nexthop >> to be loaded, so ip/ip6/inet family has the same logical now, >> for example: > > Yes, but pkt->pf is not available in init, where we have to answer what > the data size will be. In init ctx->afi->family is available, a example code is in nft_ct_get_init(), you can take a look at this. -- 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
