Re: nftables data type names

[Patrick McHardy <kaber@trash.net>]

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@trash.net> 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

 mark/realm: pkt_mark and pkt_realm/route_realm perhaps. Not sure

 uid/gid: sk_uid/sk_gid?

Any opinions on these?