From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jan Engelhardt <jengelh@inai.de>
Cc: Eric Leblond <eric@regit.org>, Phil Sutter <phil@nwl.cc>,
netfilter-devel@vger.kernel.org
Subject: Re: [nft PATH 01/16] libnftables: introduce library
Date: Mon, 21 Aug 2017 10:19:17 +0200 [thread overview]
Message-ID: <20170821081917.GD2982@salvia> (raw)
In-Reply-To: <nycvar.YFH.7.76.1708192106560.32657@n3.vanv.qr>
On Sat, Aug 19, 2017 at 09:07:55PM +0200, Jan Engelhardt wrote:
>
> On Saturday 2017-08-19 10:43, Eric Leblond wrote:
>
> >>> Hence I defined a global init and deinit. But maybe it does not
> >>> really make sense and could be attached to each context or init
> >>> could be done at first usage.
> >>
> >> My idea was to implement simple reference counting to see whether
> >> the library was already initialized and whether it is safe to
> >> deinit. Of course this needs some serialization for thread-safety.
> >>
> >> Or maybe the deinit can be ignored completely and
> >> nft_global_init() just has to check whether data is already
> >> initialized or not.
> >
> >I have used numerous libraries providing a global init or deinit.
> >For now we could easily skip it with your approach or another but I
> >prefer we have it existing so it is available later in case of
> >needs.
>
> If a global init - more correctly, a singleton init - is needed,
> can't it just implicitly be called from make_me_a_new_context()?
I would advocate for placing the nft_global_init() and deinit() code
into the ctx object too.
Those _init() and _deinit() are indeed initializing context
information, such as iproute/ct label maps.
So they are context after all.
next prev parent reply other threads:[~2017-08-21 8:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 20:42 [nft PATCH 0/16] introduce libnftables Eric Leblond
2017-08-16 20:42 ` [nft PATH 01/16] libnftables: introduce library Eric Leblond
2017-08-17 8:57 ` Phil Sutter
2017-08-17 17:09 ` Eric Leblond
2017-08-17 17:13 ` Phil Sutter
2017-08-19 8:43 ` Eric Leblond
2017-08-19 19:07 ` Jan Engelhardt
2017-08-21 8:19 ` Pablo Neira Ayuso [this message]
2017-08-16 20:42 ` [nft PATH 02/16] libnftables: add context new and free Eric Leblond
2017-08-17 9:04 ` Phil Sutter
2017-08-16 20:42 ` [nft PATH 03/16] libnftables: add nft_run_command_from_buffer Eric Leblond
2017-08-17 9:21 ` Phil Sutter
2017-08-16 20:42 ` [nft PATH 04/16] libnftables: add nft_run_command_from_filename Eric Leblond
2017-08-16 20:42 ` [nft PATH 05/16] libnftables: put nft_run in library Eric Leblond
2017-08-16 20:43 ` [nft PATH 06/16] libnftables: add missing variable to library Eric Leblond
2017-08-17 9:35 ` Phil Sutter
2017-08-19 11:02 ` Eric Leblond
2017-08-16 20:43 ` [nft PATH 07/16] libnftables: add NFT_EXIT_* " Eric Leblond
2017-08-16 20:43 ` [nft PATH 08/16] libnftables: add a nft_cache to nft_ctx Eric Leblond
2017-08-17 9:43 ` Phil Sutter
2017-08-16 20:43 ` [nft PATH 09/16] libnftables: move iface_cache_release to deinit Eric Leblond
2017-08-16 20:43 ` [nft PATH 10/16] libnftables: get rid of printf Eric Leblond
2017-08-17 10:01 ` Phil Sutter
2017-08-19 8:59 ` Eric Leblond
2017-08-16 20:43 ` [nft PATH 11/16] libnftables: add nft_context_set_print Eric Leblond
2017-08-16 20:43 ` [nft PATH 12/16] libnftables: transaction support Eric Leblond
2017-08-17 10:11 ` Phil Sutter
2017-08-16 20:43 ` [nft PATH 13/16] libnftables: set max_errors to 1 in library Eric Leblond
2017-08-16 20:43 ` [nft PATH 14/16] erec: add function to free list Eric Leblond
2017-08-16 20:43 ` [nft PATH 15/16] libnftables: add error handling Eric Leblond
2017-08-17 10:32 ` Phil Sutter
2017-08-19 9:04 ` Eric Leblond
2017-08-16 20:43 ` [nft PATH 16/16] libnftables: basic doxygen documentation Eric Leblond
2017-08-17 8:32 ` [nft PATCH 0/16] introduce libnftables Arturo Borrero Gonzalez
2017-08-17 8:58 ` Eric Leblond
2017-08-17 10:35 ` Florian Westphal
2017-08-17 10:47 ` 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=20170821081917.GD2982@salvia \
--to=pablo@netfilter.org \
--cc=eric@regit.org \
--cc=jengelh@inai.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 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).