At Wed, 05 Jun 2013 18:29:53 +0200, 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.
* While all my systems have an optical drive, I know they have disappeared from many systems, both very small and very large ones, so leaving cdrom and sr_mod as modules seems fine.
* I have no idea why/how sg is being loaded, it has no modalias and no other module depend on it. But /dev/sd* nodes are created so it is certainly useful. Hannes?
* No idea what the scsi_dh* modules are about either, no modalias and no dependencies either. Hannes?
* With DRM/KMS being the norm now, I believe drm and drm_kms_helper could be built-in, even though the former is quite large. drm selects i2c-algo-bit, most (all?) DRM/KMS drivers use it. Even servers have graphics chips.
I thought i2c-algo-bit is only about i915, but it's no big deal, it's small. The only cases where we don't need KMS are with Nvidia and AMD binary drivers. But built-in drm and drm_kms_helper are harmless except for the memory usage.
* I suppose fuse is only used on desktop machines by default, for gvfs, so having it as a module seems OK.
NTFS will use FUSE, too.
* lockd and sunrpc are dependencies of nfs and nfsd. I suppose there are many users out there who don't serve nor mount NFS shares so modules make sense.
* I think microcode could be unloaded after use, maybe for security reasons it might even be preferable, or just because there is simply no point in keeping it in memory. Thomas? Either way we should keep it modular.
The microcode driver loads the firmware by itself via request_firmware() at probe. If we build in, we'll need microcode firmware in initrd, to.
* For sound drivers, Takashi should know better than me. I suppose that the rationale for having these modular is that servers have no sound chip?
Yes. Also I'm still providing update KMP, so it's convenient to keep them as modules. pcspkr was built in ago, but this was split as a module. Making it as a module has another merit: you can blacklist it if you are annoyed by beep sound. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org