From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jeremy Sowden <jeremy@azazel.net>
Cc: Netfilter Devel <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nf-next v3 00/18] Remove config option checks from netfilter headers.
Date: Fri, 13 Sep 2019 11:27:53 +0200 [thread overview]
Message-ID: <20190913092753.wsitjcxqmzh2gxq2@salvia> (raw)
In-Reply-To: <20190913081318.16071-1-jeremy@azazel.net>
Hi Jeremy,
On Fri, Sep 13, 2019 at 09:13:00AM +0100, Jeremy Sowden wrote:
> In a previous patch-series [0], I removed all netfilter headers from the
> blacklist of headers which could not be compiled standalone. I did so
> by fixing the specific compilation failures of the headers in the list,
> usually by adding a preprocessor conditional to check whether a particu-
> lar config option was enabled and disable some function definition or
> struct member which depended on that option. While this was effective,
> it was not wholly satisfactory since it left a scattering of seemingly
> random ifdefs throughout the headers.
>
> 0 - https://lore.kernel.org/netfilter-devel/20190813113657.GB4840@azazel.net/T/
>
> The reason why these ad-hoc conditionals were necessary is that there
> were inconsistencies in how existing checks were used to disable code
> when particular options were turned off. For example, a header A.h
> might define a struct S which was only available if a particular config
> option C was enabled, but A.h might be included by header B.h, which
> defined a struct T with a struct S member without checking for C. If
> A.h and B.h were included in X.c, which was only compiled if C was
> enabled, everything worked as expected; however, trying to compile B.h
> standalone when C was disabled would result in a compilation failure.
>
> In the previous versions of this patch-series, I attempted to provide a
> more comprehensive solution by identifying the config options relevant
> to each header and adding the appropriate conditionals to it where they
> do not already exist. However, based on feedback and looking at some
> other examples, it became apparent that a better approach was to
> endeavour to fix the inconsistencies that made the new config checks
> necessary, with a view to removing as many of them as possible.
At quick glance, I like this patch series.
next prev parent reply other threads:[~2019-09-13 9:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 8:13 [PATCH nf-next v3 00/18] Remove config option checks from netfilter headers Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 01/18] netfilter: fix include guards Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 02/18] netfilter: fix coding-style errors Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 03/18] netfilter: remove unused function declarations Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 04/18] netfilter: inline three headers Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 05/18] netfilter: update include directives Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 06/18] netfilter: remove nf_conntrack_icmpv6.h header Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 07/18] netfilter: move inline function to a more appropriate header Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 08/18] netfilter: move code between synproxy headers Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 09/18] netfilter: move struct definition function to a more appropriate header Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 10/18] netfilter: use consistent style when defining inline functions in nf_conntrack_ecache.h Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 11/18] netfilter: replace defined(CONFIG...) || defined(CONFIG...MODULE) with IS_ENABLED(CONFIG...) Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 12/18] netfilter: wrap two inline functions in config checks Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 13/18] netfilter: update stub br_nf_pre_routing_ipv6 parameter to `void *priv` Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 14/18] netfilter: move nf_conntrack code to linux/nf_conntrack_common.h Jeremy Sowden
2019-09-13 9:27 ` Pablo Neira Ayuso
2019-09-13 10:30 ` Pablo Neira Ayuso
2019-09-13 8:13 ` [PATCH nf-next v3 15/18] netfilter: remove CONFIG_NF_CONNTRACK check from nf_conntrack_acct.h Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 16/18] netfilter: remove CONFIG_NETFILTER checks from headers Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 17/18] netfilter: remove CONFIG_NF_CONNTRACK checks from nf_conntrack_zones.h Jeremy Sowden
2019-09-13 8:13 ` [PATCH nf-next v3 18/18] netfilter: remove two unused functions from nf_conntrack_timestamp.h Jeremy Sowden
2019-09-13 9:27 ` Pablo Neira Ayuso [this message]
2019-09-13 10:57 ` [PATCH nf-next v3 00/18] Remove config option checks from netfilter headers Pablo Neira Ayuso
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=20190913092753.wsitjcxqmzh2gxq2@salvia \
--to=pablo@netfilter.org \
--cc=jeremy@azazel.net \
--cc=netfilter-devel@vger.kernel.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).