[-next,0/7] clean up needless use of module infrastructure

People can embed modular includes and modular exit functions into code
that never use any of it, and they won't get any errors or warnings.

Using modular infrastructure in non-modules might seem harmless, but some
of the downfalls this leads to are:

 (1) it is easy to accidentally write unused module_exit removal code
 (2) it can be misleading when reading the source, thinking a driver can
     be modular when the Makefile and/or Kconfig prohibit it
 (3) an unused include of the module.h header file will in turn
     include nearly everything else; adding a lot to CPP overhead.
 (4) it gets copied/replicated into other drivers and spreads quickly.

As a data point for #3 above, an empty C file that just includes the
module.h header generates over 750kB of CPP output.  Repeating the same
experiment with init.h and the result is less than 12kB; with export.h
it is only about 1/2kB; with both it still is less than 12kB.  One driver
in this series gets the module.h ---> init.h+export.h conversion.

Worse, are headers in include/linux that in turn include <linux/module.h>
as they can impact a whole fleet of drivers, or a whole subsystem, so
special care should be used in order to avoid that.  Such headers should
only include what they need to be stand-alone; they should not be trying
to anticipate the various header needs of their possible end users.

In this series, four include/linux headers have module.h removed from
them because they don't strictly need it.  Then three chunks of net
related code have modular infrastructure that isn't used, removed.

There are no runtime changes, so the biggest risk is a genuine consumer
of module.h content relying on implicitly getting it from one of the
include/linux instances removed here - thus resulting in a build fail.

With that in mind, allmodconfig build testing was done on x86-64, arm64,
x86-32, arm. powerpc, and mips on linux-next (and hence net-next).

Paul.

---

Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: "Rosen, Rami" <rami.rosen@intel.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yonghong Song <yhs@fb.com>
Cc: Yotam Gigi <yotam.gi@gmail.com>

Paul Gortmaker (7):
  net: psample: drop include of module.h from psample.h
  net: ife: drop include of module.h from net/ife.h
  net: fib: drop include of module.h from fib_notifier.h
  net: tc_act: drop include of module.h from tc_ife.h
  cgroup: net: remove left over MODULE_LICENSE tag
  net: bpfilter: dont use module_init in non-modular code
  net: strparser: make it explicitly non-modular

 include/net/fib_notifier.h  |  3 ++-
 include/net/ife.h           |  1 -
 include/net/psample.h       |  1 -
 include/net/tc_act/tc_ife.h |  3 ++-
 net/core/netprio_cgroup.c   |  2 --
 net/ipv4/bpfilter/sockopt.c |  3 +--
 net/strparser/strparser.c   | 14 ++++----------
 7 files changed, 9 insertions(+), 18 deletions(-)

From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Sat, 20 Apr 2019 23:29:41 -0400

> People can embed modular includes and modular exit functions into code
> that never use any of it, and they won't get any errors or warnings.
> 
> Using modular infrastructure in non-modules might seem harmless, but some
> of the downfalls this leads to are:
> 
>  (1) it is easy to accidentally write unused module_exit removal code
>  (2) it can be misleading when reading the source, thinking a driver can
>      be modular when the Makefile and/or Kconfig prohibit it
>  (3) an unused include of the module.h header file will in turn
>      include nearly everything else; adding a lot to CPP overhead.
>  (4) it gets copied/replicated into other drivers and spreads quickly.
> 
> As a data point for #3 above, an empty C file that just includes the
> module.h header generates over 750kB of CPP output.  Repeating the same
> experiment with init.h and the result is less than 12kB; with export.h
> it is only about 1/2kB; with both it still is less than 12kB.  One driver
> in this series gets the module.h ---> init.h+export.h conversion.
> 
> Worse, are headers in include/linux that in turn include <linux/module.h>
> as they can impact a whole fleet of drivers, or a whole subsystem, so
> special care should be used in order to avoid that.  Such headers should
> only include what they need to be stand-alone; they should not be trying
> to anticipate the various header needs of their possible end users.
> 
> In this series, four include/linux headers have module.h removed from
> them because they don't strictly need it.  Then three chunks of net
> related code have modular infrastructure that isn't used, removed.
> 
> There are no runtime changes, so the biggest risk is a genuine consumer
> of module.h content relying on implicitly getting it from one of the
> include/linux instances removed here - thus resulting in a build fail.
> 
> With that in mind, allmodconfig build testing was done on x86-64, arm64,
> x86-32, arm. powerpc, and mips on linux-next (and hence net-next).

Series applied, thanks Paul.