Bloat

[Andrew Doran <ad%netbsd.org@localhost>]

Someone mentioned bloat as a reason in favour of wrapping lots of small
sections of code in ifdef COMPAT_XX *. There are lots of potential reasons
to do that, but you're on crack if you think avoiding bloat is one of them.

An i386 compat module I have here is around 20kB, so that's roughtly what
the conditional part of the native compat code costs when in kernel - at
least for the version of the module I am looking at. 20kB is around 0.2% of
the size of the pre-modular i386 kernel.

For someone who has time to spare and wants to do something about bloat
other than complain, there are countless examples of it to be found on the
order of 10s or 100s of kB each -- not the odd if statement and structure
copy wrapped in #ifdef FOO, that takes 100 bytes when compiled up, providing
a useful feature in compact form. Some examples:

- There's a lot of stuff in the kernel that duplicates functionality or is
  really suspect: e.g. sysctl descriptions which are documentation, or
  subsystems like 'extent'.

- Moving a limited set of stuff out of the kernel and into modules cut about
  1.3MB from the i386 kernel. If everything reasonable that could be a
  module was made a module, the i386 kernel would be very lean indeed.

- gcc produces fat code. I heard that pcc is better in this regard. Most of
  the kernel compiles with pcc but there is a compiler bug that prevents it
  booting. Should not be too hard to isolate it.

- Removing most of the inline functions from the x86 headers for pcc and for
  modules reduced the size of the amd64 kernel by about 150kB because the
  compiler is stupid. Most of those did something extremely slow and had no
  business being inlines. It's likely there are other instances of this to
  be found.

- There are 10 or 20 drivers that use 100kB or more of text/data.

[* Reasons to avoid this style of programming include our experience of 10+
years worth of shitty problems with circular dependencies, LOCKDEBUG,
inlines, macros and other conditionals that break userland tools and hold
back decent module support. Justifications that could be offered for this
include micro optimization, bloat reduction, laziness, lack of time, and the
ability to support every concieveable feature configuration.]