revisit: turning some of the "always used" modules to built-in

[Dave Jones]

On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote:

 > Category 1: Always loaded anyway 
 > --------------------------------
 > Rationale: Since we load these always anyway, why bother making it modules
 > - ata_generic, pata_acpi

These ones make me hrmm a bit. I'd like to know that our initrd isn't
going to do something silly before we change these. Peter ?

 > - libata

Sure. Done in CVS.

 > - sg, sd_mod

Ditto.

 > , scsi_mod

This one is tricky. It seems to become modular because it's dependant upon
the bool SCSI_NETLINK. A bunch of other scsi modules enable SCSI_NETLINK,
like the fibrechannel stuff.  I'm not convinced we want to build all that
stuff in.

 > - ext3, jbd, mbcache

I'm torn on these. Mostly for the reasons both Eric and Matt suggested.
The flipside being that Eric knows how to build his own kernels, and can do so,
but at the same time, if it means he spends less time fixing ext bugs each
day and more time staring at compiler output, I'm not sure it's a net win.
Matts argument, whilst RHEL specific, does have an element of validity
for Fedora too.  We always push the 'Fedora isn't a test vehicle for RHEL'
angle, but at the same time, there's no denying that doing something completely
different does take away a certain amount of 'in the field' testing.
(In this case, I'm primarily thinking about the knock-on effects changes
like this have on the kernel periphery packages like mkinitrd/anaconda
which now have to support two separate cases).
 
 > Category 2: Always loaded in default install
 > --------------------------------------------
 > Rationale: yes you can turn off your firewall.. but nobody should do that.
 >            The others are default-loaded as well
 > - ip_tables, iptable_filter
 > - ip6_tables, ip6table_filter

Hm. Could be swayed either way on these ones.

 > - dm_mod

Yeah, I guess.

 > - ipv6

A lot of people alias this to off if they don't use it. I think we'd get
quite a few complaints if we broke that.

 > - battery, ac, button, video, output

Some of these are a bit crap in the case of 'the hardware/bios doesnt support this'.
Ie, ac will register proc entries even if there aren't any ACPI objects to
register underneath it.  Somewhat benign, but on the whole, not really a problem
per-se. I suppose we could flip these on.

 > - ahci (default storage for all new systems; means that there the system 
 >         always has the / device driver)

Same thing as above. The mkinitrd logic surrounding ordering of storage
modules is fragile at best..

 > - ehci_hcd (means you have a USB keyboard early)

ISTR there was some issue with this. I'm sure we even tried it once
in the FC2 era.  Lets give it a shot, and see what happens.

 > - cpufreq_ondemand (means the cpu can slow down for power/thermal)
 > - acpi_cpufreq (means the cpu can slow down for power/thermal)

On Intel this is a good idea. On other CPUs, acpi-cpufreq is considered
a fallback 'last resort' driver. 
 
 > Rationale: pretty much always loaded in default installs
 > - snd_seq_dummy, snd_seq, snd_seq_device, 
 >   snd_pcm, snd_timer, snd_page_alloc, snd
 
The only concern here seems to be the one of memory bloat.
ALSA isn't the smallest part of the kernel, and if some folks are
currently aliasing that off in their modules.conf, we'll probably
upset them with such a change.

	Dave

-- 
http://www.codemonkey.org.uk