Re: nftables data type names

[Patrick McHardy <kaber@trash.net>]

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.