On Sun, Apr 13, 2014 at 12:57:53PM +0200, Patrick McHardy wrote: > On Sat, Apr 12, 2014 at 01:03:53PM +0200, Patrick McHardy wrote: > > On Sat, Apr 12, 2014 at 12:56:46PM +0200, Florian Westphal wrote: > > > Patrick McHardy <kaber@xxxxxxxxx> wrote: > > > > Before the upcoming release, I'd like to add some more consistency among > > > > nftables data type names. We currently have the following types: > > > [..] > > > > In some cases we're more verbose, in other we're using abrevations. > > > > I'd like to decide for either one. > > > > > > > > > > I like ether_type/ether_addr. > > > ... > > > Fully agree, more consistency would be good. > > > > Thanks for the feedback, I'll post a patch soon. > > What I've got now is: > > Address types: > > ll_addr > ipv4_addr > ipv6_addr > ether_addr > > Protocol types: > > nf_proto > inet_proto > > (l3proto and l4proto don't exist as types) > > Conntrack types: > > ct_state > ct_dir > ct_status > ct_label > > Packet type related types: > > mh_type > iface_type > icmp_type > dccp_pkttype > icmpv6_type > ether_type > > Interface related types: > > ifindex > iface_type > > Arp types: > > arp_op > > Other types: > > mark > time > realm > uid > gid > > And a few base types that are fine as they are. > > The things I'm not sure about are: > > ifindex: this is a well established term I think, however it would be more > consistent to use iface_index We can have an alias for this perhaps so both work? > mark/realm: pkt_mark and pkt_realm/route_realm perhaps. Not sure if we would ever have ct_mark, then the initial pkt_ prefix is good to have. > uid/gid: sk_uid/sk_gid? I like the sk_ prefix also clearly specifies to users that this is related to the socket information. So following prefix_keytype looks good to me. The prefix just denotes the scope for which the keytype applies. -- 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
