On Fri, Oct 21, 2016 at 02:17:11PM +0800, Liping Zhang wrote: > 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. ctx->afi->family indicates NFPROTO_INET in this case, so we have no way to know if the user is requesting rt IPv4 or rt IPv6 from there. -- 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
