Re: Bloat

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Sun Jan 25 2009 at 20:08:42 +0000, Andrew Doran wrote:
> 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.
> 
> - 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.

While not directly related to bloat, here's some brainfuel: inline is also
evil because it destroys the barrier between interface and implementation.
I'm frequently hitting barrier this with rump.  People doing builds on
esoteric archs are probably hitting it too because of me.  And before
anyone barks out that nobody cares about rump, gotcha, the same thing
applies to reasoble ABI stability as well.

In fact, I'd like to see a policy where we require a measurement
and evaluation of the benefit of introducing new inlines or "clever"
cpp trickery.  (no, benchmarks run on vaxen don't count).

> [* 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.]

Your list contains two valid justifications: laziness and lack of time.
Maybe they slipped in there by accident?