[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter-devel
Subject:    Re: [nft PATCH 8/9] JSON: Make match op mandatory, introduce 'in' operator
From:       Phil Sutter <phil () nwl ! cc>
Date:       2018-08-30 15:10:34
Message-ID: 20180830151034.GR28016 () orbyte ! nwl ! cc
[Download RAW message or body]

Hi Pablo,

On Thu, Aug 30, 2018 at 12:24:11PM +0200, Pablo Neira Ayuso wrote:
> On Wed, Aug 29, 2018 at 04:23:27PM +0200, Phil Sutter wrote:
> > diff --git a/doc/libnftables-json.adoc b/doc/libnftables-json.adoc
> > index 309988bcf02af..c174a35487d46 100644
> > --- a/doc/libnftables-json.adoc
> > +++ b/doc/libnftables-json.adoc
> > @@ -577,8 +577,6 @@ processing continues with the next rule in the same chain.
> >  	Operator indicating the type of comparison.
> >  
> >  ==== OPERATORS
> > -The operator is usually optional and if omitted usually defaults to "==".
> > -Allowed operators are:
> >  
> >  [horizontal]
> >  *&*:: Binary AND
> > @@ -592,6 +590,17 @@ Allowed operators are:
> >  *>*:: Greater than
> >  *<=*:: Less than or equal to
> >  *>=*:: Greater than or equal to
> > +*in*:: Perform a lookup, i.e. test if bits on RHS are contained in LHS value
> 
> Applied, but only one comment on this one, 'in' maps to the internal
> implicit operation? I'm a bit confused about this one.

No worries, it *is* confusing. :)

In standard API we have this implicit op which we internally treat as
OP_EQ with one exception which is bitmask on RHS. IIRC, treating absense
of "op" property differently from it being there with value "==" was
deemed inappropriate for JSON API. So I had to find an alternative to
implicit OP just for the bitmask case, so I made up "in".

If you have a better idea for this, I'm all for it. IMHO the real issue
is that shortcut from 'expr1 & expr2 != 0' to 'expr1 expr2', although it
is quite intuitive in practice.

Actually, I could just drop the "in" operator and force users to build
that lookup manually. Not sure if that's the better option. Right now it
is at least a bit unclear when to use "==" or "in", mostly due to lack
of documentation.

Cheers, Phil
[prev in list] [next in list] [prev in thread] [next in thread]