On Wednesday, June 05, 2013 06:29:53 PM Jean Delvare wrote:
Hi all,
Having worked on built-in drivers which could be modularized, I am now looking for modular drivers which could be built-in. Our policy is that drivers which are not hardware-specific and are needed on a majority of systems should be built into the kernel directly.
So I checked which modules were loaded on my 4 systems. After filtering out hardware-specific modules, I am left with the following list:
ACPI and thermal drivers: * button * processor * thermal_sys
Block device drivers * cdrom * scsi_dh * scsi_dh_alua * scsi_dh_emc * scsi_dh_hp_sw * scsi_dh_rdac * sg * sr_mod
Graphics helper drivers * drm * drm_kms_helper * i2c_algo_bit
Filesystem drivers: * fuse * lockd * sunrpc
CPU drivers: * microcode
Sound drivers: * pcspkr * snd * snd_page_alloc * snd_pcm * snd_seq * snd_seq_device * snd_timer * soundcore
If anyone has an opinion on whether these should be built into the kernel or left as modules, this is the right time to discuss it. My personal thoughts, with mostly x86 in mind:
* The ACPI button and processor drivers could be built-in. Most x86 systems use ACPI and they supposedly all have at least one processor and one power button ;) And thermal_sys is selected by processor. There still is the acpi_processor_load_module() function in: drivers/acpi/processor_perflib.c which tries to load acpi_cpufreq.ko which might not work if processor.ko is built in. But this should not be needed since acpi_cpufreq is tried to be loaded via acpi CPU capability flag and the function should just vanish.
There might be side effects with processor.ko as quite some stuff depends on it (e.g. must get active after intel_idle driver or acpi_idle is registered first and possibly other side-effects), but in general this should work or it's a bug. Hm, can someone double check whether processor is compiled in on other distros? If not, we should not be the first doing it and run into unforseen problems. No objections with the button driver. ...
* I think microcode could be unloaded after use, Hm, could this be done inside the module already? microcode driver could always return a negative value in its init function whether it could load a firmware file or not. (unless microcode.keep=1 is passed if one wants to examine something)
This would avoid: modprobe microcode rmmod microcode userspace control and possible race conditions. Does this make sense? Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org