All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>,
	netfilter-devel@vger.kernel.org, Eric Leblond <eric@regit.org>,
	Florian Westphal <fw@strlen.de>
Subject: Re: libnftables, next steps
Date: Mon, 16 Oct 2017 12:19:51 +0200	[thread overview]
Message-ID: <20171016101904.GA32102@salvia> (raw)
In-Reply-To: <20171004225152.GD32278@orbyte.nwl.cc>

Hi Phil,

Sorry it took a while to get back to you.

On Thu, Oct 05, 2017 at 12:51:52AM +0200, Phil Sutter wrote:
> Hi!
> 
> I rebased Eric's libnftables patch series onto current master to get an
> overview of what's still missing (and what I could work on :). Here's
> what I collected:
> 
> * Implement application accessible batch support.
>   -> This basically splits nft_run() into stages.
>   -> I would change nft_run_cmd_from_*() to use this internally.
>   -> Do we want this in the early library version or is this going to be
>      part of the 'advanced API' to add later?

I would leave this behind. Let's just start with the most simple API,
then we move on.

> * Add erec_free_list().
>   -> This becomes handy if the application wants to drop erec list
>      without printing it (erec_print_list() clears the list while
>      traversing it).
>
>   -> No use for this if we only export nft_run_cmd_from_*() functions.

OK, so this is part of the advanced API then.

> * Create src/nftables_common.c and include/nftables_common.h to hold
>   nft_run() and nft_netlink().

Why not just place this in src/libnftables.c?

>   -> Is this meant as the (not exported) high-level library backend?
>   -> If batch support is implemented, these could be removed after
>      changing nft_run_cmd_from_*() and cli_complete() to use it.
> 
> * Move library routines from src/main.c into src/libnftables.c and
>   create include/nftables/nftables.h to hold the signatures.
> 
> * Introduce the library (i.e., generate libnftables.so).
> 
> Some additional thoughts:
> 
> * Should we support different output streams for debug and/or error
>   messages?

What usecase you have in mind for this?

> * Should we reuse src/erec.c for regular output as well? (This probably
>   needs a 'print immediately' switch for monitor mode, though.)

Again, same question.

> Feedback highly appreciated, of course! Should I start with moving the
> library stuff into libnftables.{c,h} so we get an impression of what the
> API will look like?

I think Eric doesn't have time at this stage, so if you can take his
patches, revamp and resubmit, that would be great.

Thanks!

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

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 22:51 libnftables, next steps Phil Sutter
2017-10-16 10:19 ` Pablo Neira Ayuso [this message]
2017-10-16 15:45   ` 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=20171016101904.GA32102@salvia \
    --to=pablo@netfilter.org \
    --cc=eric@regit.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /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.