Re: [PATCH-next v3] netfilter: don't use module_init/exit in core IPV4 code

[Patrick McHardy <kaber@trash.net>]

On Thu, Jan 16, 2014 at 03:24:03PM -0500, Paul Gortmaker wrote:
> The file net/ipv4/netfilter.o is created based on whether
> CONFIG_NETFILTER is set.  However that is defined as a bool, and
> hence this file with the core netfilter hooks will never be
> modular.  So using module_init as an alias for __initcall can be
> somewhat misleading.
> 
> Fix this up now, so that we can relocate module_init from
> init.h into module.h in the future.  If we don't do this, we'd
> have to add module.h to obviously non-modular code, and that
> would be a worse thing.  Also add an inclusion of init.h, as
> that was previously implicit here in the netfilter.c file.
> 
> Note that direct use of __initcall is discouraged, vs. one
> of the priority categorized subgroups.  As __initcall gets
> mapped onto device_initcall, our use of subsys_initcall (which
> seems to make sense for netfilter code) will thus change this
> registration from level 6-device to level 4-subsys (i.e. slightly
> earlier).  However no observable impact of that small difference
> has been observed during testing, or is expected. (i.e. the
> location of the netfilter messages in dmesg remains unchanged
> with respect to all the other surrounding messages.)
> 
> As for the module_exit, rather than replace it with __exitcall,
> we simply remove it, since it appears only UML does anything
> with those, and even for UML, there is no relevant cleanup
> to be done here.

Just to bring up the idea: there's no reason why we couldn't make
netfilter fully modular for individual AFs. I've seen quite a lot
of embedded systems that include the IPv6 netfilter core without
using it.

Its rather complicated to get all the dependencies of xtables
modules right though, so this is really just to bring up the
idea.

Your patch looks fine to me.