On Tue, Mar 01, 2016 at 12:00:55PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > Ok, but how do you plan to handle the key length?
> >
> > Right, in concatenations we can infer this from the lhs, but in set
> > definitions there is not way.
>
> Okay. So whats the plan there?
I would review Carlos' patches, recover Patrick patch to add typeof()
and check if we can get all the pieces together to support this.
> > What I would suggest is to recover a patch that Patrick submitted that
> > introduces typeof(X) so we can use this from set definitions. We can
> > store in the TLV the original subtype X as a string. Thus, when
> > listing back to userspace we can use this information to display back
> > the typeof(X).
>
> So you mean you'd use something like
>
> nft add set filter ifnames '{typeof(meta iifname); }' ?
>
> That should indeed work since we can derive the size
> from the meta iifname (or whatever other field),
>
> > We have to potentially support every meta and packet selector,
> > including crazy ones as 48 bits fields, and last time we discussed
> > this, we agreed that adding one type per field size is not the way to
> > go.
>
> Ok, yes, I see your point.
>
> > Let me know your opinion on this, thanks!
>
> I think typeof would be good; we could indeed derive the key size with
> this without the need for a new type.
Yep, we have a plan to address this then.
--
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
