Re: nft typeof keywork patch

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, Sep 15, 2017 at 01:02:43PM +0200, Florian Westphal wrote:
> > > Wait, so
> > >     nft add set ip filter set1 { typeof ip saddr;}
> > > 
> > > then it should not list
> > >     nft add set ip filter set1 { type ipv4_addr;}
> > > 
> > > but the exact input using the typeof()?
> > > 
> > > I wonder how to encode this, especially given we also need to support
> > > concatenation, e.g.
> 
> I've started with this, first item i am working on is to change
> struct set to pass in struct expr *key instead of datatype+len to make
> the original expression (meta iifname for example) available to the
> linerize parts so we can stash this info in the udata.
> 
> For "typeof(meta iifname) . mark" case the parser will generate a concat
> expression, and, since these keep the original expr around we can
> iterate over that list to get back the original expressions.

Yes, a list is going to be much cleaner and I would expect it simplies
the code. I remember Carlos Falgueras sent me a patch for this in a
batch he made, however, for whatever reason it never reached upstream.

> For the normal 'type' case, i think we can simply use a dummy
> constant expression to serve as a container for the data type.
> 
> What do you think?

Sounds reasonable, give a shot.