| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 02 Jun 2008 21:13:13 -0700 From: Justin Madru <jdm64@...ab.com> To: lkml <linux-kernel@...r.kernel.org> Subject: [Question] about modules/inline benefits Hi, I've been compiling linus' git kernel (recompiling every -rc). I usually compile many features/drivers as modules. I was wondering what the benefits/drawbacks there are for modules compared to inlining. What would be the differences between modules and inlining if you know the hardware/features needed? Is it better to not use modules if you're compiling for just one computer that you know the hardware/features needed? (I know distros have to use modules because they have to work on a wide variety of hardware) Are there any performance/efficiency/memory benefits for inlining/module? Are some drivers/features better suited to be compiled as modules? Do modules slow down the boot process? I currently have these modules: i915 acpi_cpufreq cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative container sbs sbshc ext3 jbd mbcache arc4 ecb crypto_blkcipher rtc dcdbas cryptomgr crypto_algapi psmouse evdev snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm iwl3945 mac80211 snd_timer crc32 snd_page_alloc video backlight output ac button battery intel_agp reiserfs sr_mod cdrom sg ata_piix ehci_hcd uhci_hcd usbcore thermal processor fan If inlining is more efficient/advantageous, then I might compile-in everything I can, and use modules for testing new features and such. Justin Madru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists