В Wed, 05 Jun 2013 18:29:53 +0200
Jean Delvare
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.
I agree for x86. I guess other platforms have different defconfigs anyway?
* 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.
+1
* 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?
/usr/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", IMPORT{builtin}="kmod load sg" I do not think it is needed much; the practical problem is to make sure it is loaded *when* it is needed (like remote SCSI enclosure monitoring via SES or jukebox control).
* No idea what the scsi_dh* modules are about either, no modalias and no dependencies either. Hannes?
they are related to device-mapper-multipath and not needed on normal end user systems. I wonder why they are loaded; do you have multipath enabled?
* 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.
Will it prevent proprietary drivers from working? There are quite a number of users with nVidia/ATI third party drivers. As much as I would like to not use them, nouveau still has fat too much usability issues for me.
* I suppose fuse is only used on desktop machines by default, for gvfs, so having it as a module seems OK.
* 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.
+1 to all three
* 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?
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org