From: Phil Sutter <phil@nwl.cc>
To: netfilter-devel@vger.kernel.org
Cc: Eric Leblond <eric@regit.org>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Florian Westphal <fw@strlen.de>
Subject: libnftables, next steps
Date: Thu, 5 Oct 2017 00:51:52 +0200 [thread overview]
Message-ID: <20171004225152.GD32278@orbyte.nwl.cc> (raw)
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?
* 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.
* Create src/nftables_common.c and include/nftables_common.h to hold
nft_run() and nft_netlink().
-> 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?
* Should we reuse src/erec.c for regular output as well? (This probably
needs a 'print immediately' switch for monitor mode, though.)
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?
Cheers, Phil
next reply other threads:[~2017-10-04 22:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-04 22:51 Phil Sutter [this message]
2017-10-16 10:19 ` libnftables, next steps Pablo Neira Ayuso
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=20171004225152.GD32278@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 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.