Built-in modules review

[Andy Whitcroft]

On Tue, Mar 16, 2010 at 01:01:23PM -0400, Chase Douglas wrote:

> I'm trying to figure out the rationale for the decision to include
> only some of the SATA modules. If it's really size in the kernel, then
> it can make sense to only statically include those modules that are
> used often. But there's a tradeoff in speed I assume, so we're sort of
> telling one group of people that they have popular hardware so we are
> giving them the benefit of speed, but we tell the other group that
> they don't have popular hardware, so we aren't giving them the benefit
> of speed.
> 
> This type of decision sort of gets us down a path of decisions that
> are not easily distinguishable. People will start to wonder why some
> vendor drivers are included and others are not. If there's a steep
> drop off where 99% of users use 3 drivers, and 1% use the other 10
> drivers (or however many there are), then this approach can be
> articulated easily. But if the gap is more like 33% use the top 3
> drivers and 66% use the other 10 drivers, then our stance will be less
> clear.
> 
> It can also make maintenance harder. If all the modules are static or
> dynamic, then we will see the same issues across them. But if we move
> the lesser used modules to the initramfs to be loaded dynamically then
> we may not have thorough testing on them and we might not find
> regressions due to the loading process itself.
> 
> What do we really lose by statically building all the SATA modules in?
> Is there a known value here, or are we just assuming that there's some
> large cost?

We are already in the position actually where some SATA and indeed some
PATA drivers are not builtin, I suspect this is because they are newer
drivers.  What we have is an arbitrary subset built in, and we want to
move to a more selective set builtin, with a more coherant reason.

We have seen a number of issues from generally pulling things in.  We are
in a less flexible position for any driver which is built-in.  For one it
cannot be overridden in a backports module, options are more difficult
to change, and sometimes no longer changable.  As a result we have a
preference for things to be modular where that is not too high a cost.
This is expecially true where we have a long term support release on our
hands as there will be more unknown issues coming down the pipe for longer.

As an example we have a number of issues which were only triggered
when we brought all of the PATA drivers into the kernel in Karmic.
Ordering was no longer controllable and in some cases the wrong driver
loaded due to link ordering.  This led to the requirement to build new
kernels for these users, a very undesirable situation.  Indeed one which
has triggered this review.

What I am trying to say is that there is a cost for not building them in,
but there is also a cost for building them in.  The cost for 'not' is a
very small boot penalty, the cost 'for' is the flexibility for us to configure, update,
and replace drivers on an ongoing basis.

Yes we are saying some h/w is more popular and therefore gets slightly
different treatment, but that would not be a new precident.  We enabled
KMS on i915 first because it worked there better.  Expediency always
colours our choices.

-apw