From mboxrd@z Thu Jan  1 00:00:00 1970
From: Patrick McHardy <kaber@trash.net>
Subject: Re: nftables data type names
Date: Sun, 13 Apr 2014 16:21:02 +0200
Message-ID: <20140413142102.GA3375@macbook.localnet>
References: <20140412102901.GA8090@macbook.localnet>
 <20140412105646.GJ31953@breakpoint.cc>
 <20140412110352.GA15624@macbook.localnet>
 <20140413105751.GA1188@macbook.localnet>
 <20140413123728.GA26141@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
To: Pablo Neira Ayuso <pablo@netfilter.org>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from stinky.trash.net ([213.144.137.162]:52301 "EHLO
	stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752152AbaDMOVH (ORCPT
	<rfc822;netfilter-devel@vger.kernel.org>);
	Sun, 13 Apr 2014 10:21:07 -0400
Content-Disposition: inline
In-Reply-To: <20140413123728.GA26141@localhost>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

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.