Hi Liping, On fre, 2016-10-21 at 10:06 +0800, Liping Zhang wrote: > Hi Anders, > > 2016-10-20 21:52 GMT+08:00 Anders K. Pedersen | Cohaesio <akp@cohaesi > o.com>: > > OK, so would it be okay to replace it with > > > > printk_once(KERN_WARNING KBUILD_MODNAME " Address families do not > > match\n"); > > > > ? > To this question, I think it's better to do NFT_BREAK sliently, the > warning > message seems useless. Actually this can be avoided in userspace, > i.e. in nft. Well, as mentioned the suggested userspace implementation for nft does avoid it by requiring 'ether type' to be specified, when rt nexthop is used from the inet family, so I found it reasonable to issue a warning, if it happened anyway. But okay, I see your point, and I'll remove the warning. > For example, if you add the following rule in the inet family: > # nft add rule inet filter output ip daddr 1.1.1.1 > > An implict rule will be added, and this can also be applied to rt > expr, > we should first compare nfproto is AF_INET or not: > [ meta load nfproto => reg 1 ] > [ cmp eq reg 1 0x00000002 ] > > 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 ;. > 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. Regards, Anders��.n��������+%������w��{.n����z�����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
