Built-in modules review

[Chase Douglas]

On Tue, Mar 16, 2010 at 12:04 PM, Andy Whitcroft <apw at canonical.com> wrote:
> On Tue, Mar 16, 2010 at 11:51:58AM -0400, Chase Douglas wrote:
>> On Tue, Mar 16, 2010 at 11:08 AM, Andy Whitcroft <apw at canonical.com> wrote:
>> > ATA Drivers: we have the majority of the PATA and SATA drivers built in.
>> > We already have reported issues with the PATA drivers where blacklisting
>> > could be used as a work around if they were not built in.  We are also
>> > exposing users to some level of risk including all these drivers which
>> > are not used.  In testing on the reference platform I did see a minor
>> > but measurable performance hit to modularising the SATA driver there.
>> > As we are moving to SATA over time I would propose we pull out all of
>> > the PATA drivers and build in only the 2 or 3 most common SATA drivers.
>>
>> I'm not sure I understand the reasoning for including some, but not
>> all, of the SATA drivers. If the drivers are mature, and we don't have
>> or foresee any issues with particular drivers, then why modularize
>> them? The main reason I see for modularization is if there's active
>> and useful development versions that people need to fix individual
>> issues and/or add features. I can see that being the case for
>> something like HID drivers, but most, if not all, SATA drivers should
>> be mature in both stability and features at this point, right?
>
> I think that the logical extension to that position is that we should
> build in everything which is old and stable?  All the drivers which are
> built-in get at least initialised which may not be beneficial.  Also they
> increase the size of the kernel itself.  There is a trade off to be had
> between those we use often and therefore can benefit from being built-in
> against those which would only load on one machine in 1000.  IMO.

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?

-- Chase