netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Eric Leblond <eric@regit.org>,
	netfilter-devel@vger.kernel.org, Florian Westphal <fw@strlen.de>
Subject: Re: [nft PATCH 4/7] cli: Use nft_run_cmd_from_buffer()
Date: Fri, 20 Oct 2017 23:05:38 +0200	[thread overview]
Message-ID: <20171020210538.GK32305@orbyte.nwl.cc> (raw)
In-Reply-To: <20171020191807.GD1600@salvia>

On Fri, Oct 20, 2017 at 09:18:07PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Oct 20, 2017 at 07:10:18PM +0200, Phil Sutter wrote:
> > On Fri, Oct 20, 2017 at 02:15:34PM +0200, Pablo Neira Ayuso wrote:
> > > On Thu, Oct 19, 2017 at 10:18:44AM +0200, Phil Sutter wrote:
> > > > This simplifies CLI code and allows to reduce libnftables API by not
> > > > exporting nft_run().
> > > > 
> > > > Since nft_run_cmd_from_buffer() takes care of scanner initialization and
> > > > libmnl socket passed to cli_init() is present as nft_ctx field as well,
> > > > signature of cli_init() can be reduced to just take nft_ctx pointer as
> > > > single argument.
> > > 
> > > libmnl socket is indeed in nft_ctx, but we're planning a mode that
> > > allows to expose the mnl_socket for advanced handling. In that
> > > scenario, nft->nf_sock will be null.
> > > 
> > > So I would prefer we don't do changes that we have to undo once the
> > > advanced API is in place.
> > 
> > IMHO this doesn't contradict what the patch does. Right now we only have
> > the "simple API", and the patch changes src/cli.c to use just that. CLI
> > code doesn't need anything which is not fulfilled by simple API at this
> > point, so I'd say changing it to use advanced API should be done when we
> > implement features (e.g. transaction control) there.
> > 
> > What do you think?
> 
> I have no strong objection against this, I just would like we don't
> lose track of the high level API, and that one will need to expose the
> netlink socket. So all these calls we will end up needed the nf_sock
> parameter again at some point.
> 
> I don't have any strong opinion against this, just an observation.

I'd suggest to review things again once we have a common view of how the
advanced API will look like. Right now, CLI is fine with using the
simple API as proposed by my patches, so passing it ctx->nf_sock
separately just to have it either ignore it or reassign it to
ctx->nf_sock again doesn't make sense to me.

Cheers, Phil

  reply	other threads:[~2017-10-20 21:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19  8:18 [nft PATCH 0/7] libnftables preparations Phil Sutter
2017-10-19  8:18 ` [nft PATCH 1/7] nft_ctx_free: Fix for wrong argument passed to cache_release Phil Sutter
2017-10-20 12:01   ` Pablo Neira Ayuso
2017-10-19  8:18 ` [nft PATCH 2/7] libnftables: Move library stuff out of main.c Phil Sutter
2017-10-20 12:12   ` Pablo Neira Ayuso
2017-10-20 17:02     ` Phil Sutter
2017-10-20 19:08       ` Pablo Neira Ayuso
2017-10-19  8:18 ` [nft PATCH 3/7] libnftables: Introduce nft_ctx_flush_cache() Phil Sutter
2017-10-20 12:13   ` Pablo Neira Ayuso
2017-10-20 17:05     ` Phil Sutter
2017-10-20 19:10       ` Pablo Neira Ayuso
2017-10-20 21:00         ` Phil Sutter
2017-10-19  8:18 ` [nft PATCH 4/7] cli: Use nft_run_cmd_from_buffer() Phil Sutter
2017-10-20 12:15   ` Pablo Neira Ayuso
2017-10-20 17:10     ` Phil Sutter
2017-10-20 19:18       ` Pablo Neira Ayuso
2017-10-20 21:05         ` Phil Sutter [this message]
2017-10-19  8:18 ` [nft PATCH 5/7] libnftables: Introduce nft_ctx_set_dry_run() Phil Sutter
2017-10-19  8:18 ` [nft PATCH 6/7] libnftables: Provide an API for include path handling Phil Sutter
2017-10-20 12:17   ` Pablo Neira Ayuso
2017-10-20 17:16     ` Phil Sutter
2017-10-20 19:16       ` Pablo Neira Ayuso
2017-10-20 21:12         ` Phil Sutter
2017-10-19  8:18 ` [nft PATCH 7/7] libnftables: Add remaining getters and setters Phil Sutter
2017-10-20 12:18   ` Pablo Neira Ayuso
2017-10-20 16:08     ` Phil Sutter

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=20171020210538.GK32305@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=eric@regit.org \
    --cc=fw@strlen.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).