Built-in modules review

[Stefan Bader]

Andy Whitcroft wrote:
> During the karmic cycle we built-in a number of modules.  Some as part
> of the removal of udev random module loading, and some as a part of
> trying to speed up the boot.  At that time modprobe was significantly
> slower than it is now and it is appropriate to review that decision.
> 
> We have also had a number of problems reported wherein people can no
> longer parameterise their modules as they wish and/or replace them
> easily to test updated features.  In one specific case the wrong PATA
> driver is binding to the device and as it is built-in there is no longer
> a remedy.
> 
> I have prepared a summary of the sub-systems and drivers as built-in
> currently and added them to the blueprint kernel-lucid-config-review's
> spec, at the URL below:
> 
>     http://tinyurl.com/ygvwbks

I think at some time the definition was boot essential as to make the common
boot speed faster. AS the module loading is much faster I think the issue is
probably reduced to have a kernel which might be used without a initramfs under
the right circumstances. Wheren't server or virtual kernels used that way?
And if that is required in some cases keep the configuration common if it does
not hurt.

> Filesystems: we currently have all of the ext2,3,4 filesystems builtin,
> plus all of the diagnostics filesystems (procfs et al), and also fuse.
> Other than FUSE these are all boot essential.  I believe FUSE is
> required for automounting which needs confirmation.  No changes
> required.
> 
> Subsystems: of those listed the only one which appears to be a
> candidate for modularising is netfilter, I cannot recall this being
> required builtin.
> 
> Network Protocols: again these seem reasonable, the only candidates for
> review being DCB and XFRM, if anyone can confirm that we need those.
> 
> 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 think none of the PATA drivers are required to boot without initramfs while
the most common SATA drivers might be. So It sounds reasonable to proceed that way.

> Input drivers: here most things are modules already.  TOUCHSCREEN and
> TABLET are possible candidates for modularising.
> 
> HID drivers: we already took action to move HID to modules and most of
> the actual drivers already appear to be modules.  No changes required.
> 
> If people are in agreement I will put together a patch set to make these
> changes.
> 
> Comments?

I think there was a comment on bluetooth somewhere being inconsistent. We likely
want that as a module everywhere because compat-wireless includes it.

> -apw
>