On Sun, Apr 13, 2014 at 02:37:28PM +0200, Pablo Neira Ayuso wrote: > On Sun, Apr 13, 2014 at 12:57:53PM +0200, Patrick McHardy wrote: > > > > 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? Sure. We have to decide for one for output however. I'd prefer to use iface_ for consistency. > > 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. Well, its the data type, so ct_mark is unlikely to exist since the ct marks are effectively packet marks. This is also the reason why I chose "mark" without a prefix in the first place, but I now think using pkt_mark for both is more precise about what the meaning of these values is. > > uid/gid: sk_uid/sk_gid? > > I like the sk_ prefix also clearly specifies to users that this is > related to the socket information. Ok, will change. > So following prefix_keytype looks good to me. The prefix just denotes > the scope for which the keytype applies. Yep. -- 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
