All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Kristian Evensen <kristian.evensen@gmail.com>,
	Netfilter Development Mailing list
	<netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH libnftables] Add support for ct set
Date: Fri, 10 Jan 2014 19:20:38 +0000	[thread overview]
Message-ID: <20140110192037.GA6297@macbook.localnet> (raw)
In-Reply-To: <20140110191025.GA8905@localhost>

On Fri, Jan 10, 2014 at 08:10:25PM +0100, Pablo Neira Ayuso wrote:
> On Fri, Jan 10, 2014 at 06:06:25PM +0000, Patrick McHardy wrote:
> > On Fri, Jan 10, 2014 at 03:32:52PM +0100, Pablo Neira Ayuso wrote:
> > > 
> > > So are you proposing to add a new object for statements in
> > > libnftables? That will require a new infrastructure which would be
> > > very similar to what we have in the current expressions.
> > 
> > Well, the infrastructure should be pretty small. In fact you could
> > probably map everything to expressions internally (although I don't
> > think adding new infrastructure would be much effort), I would just
> > rather not create an API that confuses fundamental types.
> 
> libnftables is the very low level library, as it is very close to the
> kernel details, I would stick to the expression simplification that we
> have in the kernel.

Ok sure. Just wanted to bring it up.

> > > To that extend, that would also require a new infrastructure in the
> > > kernel so we also have statements there. I think one of the good
> > > things of the nf_tables kernel side is that we didn't make any
> > > distinction between matches/targets (or call it
> > > expressions/statements).
> > 
> > In the kernel that was deliberate and is only internal to the kernel
> > (well, and libraries and so on). I considered it, but I think in the
> > kernel its more important to keep the code base and APIs as small 
> > as possible.
> 
> Anyone working with libnftables should be familiar with the kernel
> code, the current approach maps 1 to 1 what we have in the kernel.
> 
> I still think the statement/expression concept should remain in the
> scope of nft. We'll have a high level library at some point, I guess
> that will be based on the (generalized) nft code, so we can provide
> a nft_compile() function similar to what libpcap provides to translate
> nft syntax to rules.
> 
> My proposal is to leave the expressions / statements concepts to the
> scope of nft and the upcoming high level library. As said, libnftables
> is low level stuff, it is just mirroring what we have in the kernel.

Ok that's fine with me for a low level library. Wondering whether the
high layer library should actually be called libnftables though.

  reply	other threads:[~2014-01-10 19:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-10 13:10 [PATCH libnftables] Add support for ct set Kristian Evensen
2014-01-10 13:14 ` Patrick McHardy
2014-01-10 13:19   ` Kristian Evensen
2014-01-10 13:27     ` Patrick McHardy
2014-01-10 13:33       ` Kristian Evensen
2014-01-10 13:43         ` Patrick McHardy
2014-01-10 13:52           ` Patrick McHardy
2014-01-10 14:03             ` Kristian Evensen
2014-01-10 13:54           ` Pablo Neira Ayuso
2014-01-10 13:58             ` Patrick McHardy
2014-01-10 14:32               ` Pablo Neira Ayuso
2014-01-10 18:06                 ` Patrick McHardy
2014-01-10 19:10                   ` Pablo Neira Ayuso
2014-01-10 19:20                     ` Patrick McHardy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-01-07 15:15 Kristian Evensen
2014-01-07 17:13 ` Arturo Borrero Gonzalez
2014-01-07 17:28   ` Kristian Evensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140110192037.GA6297@macbook.localnet \
    --to=kaber@trash.net \
    --cc=kristian.evensen@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.