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
next prev parent 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).