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
Justin Madru wrote:
> 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.
I mentioned one difference on the kernel-testers list (
http://article.gmane.org/gmane.linux.kernel.kernel-testers/42 ) not so long
ago - inlining everything leads to a slightly quicker build and you can
skip the mkinitrd step if your system is simple enough. It also means you
can get away with only having to move one file to install a kernel (e.g. on
another machine).
I suspect that inlining leads to a fractionally faster boot but not so that
one would really notice.
Some distro userspace startup scripts become grouchy if they can't load
particular modules.
Modules can sometimes be unloaded which can workaround other problems (e.g.
I have a wifi device that is broken after resuming from hibernate but when
it's a module the distro scripts will unload / reload it). Supposedly there
are no guarantees that all modules will have done perfect clean up when
unloaded though.
Modules can be blacklisted preventing them from being loaded in the first
place.
Modules allow you to support more hardware as there is a maximum size of the
core kernel image.
A module can be rebuilt without having to relink the whole kernel. This can
be a time saver.
Some features will only be selectable if something that has a choice of
being a module or inlined is inlined.
Some features are only available as modules.
Having module loading turned off can be seen as a step towards hardening the
kernel against certain types of rootkit (you would have to do other things
like locking down /dev/kmem though and it won't stop people ascending to
root via exploits but might mitigate the after effects).
Building things as modules versus building them inline can sometimes expose
bugs due to races not seen when using the other method.
--
Sitsofe | http://sucs.org/~sits/
Am Dienstag 03 Juni 2008 09:28:59 schrieb Sitsofe Wheeler:
> Modules allow you to support more hardware as there is a maximum size of the
> core kernel image.
But you pay for every module with half a page of unused RAM and module
code will be in vmalloced memory thus increases TLB pressure a bit.
Regards
Oliver
On Tue, Jun 03, 2008 at 09:54:41AM +0200, Oliver Neukum wrote:
> Am Dienstag 03 Juni 2008 09:28:59 schrieb Sitsofe Wheeler:
> > Modules allow you to support more hardware as there is a maximum size of the
> > core kernel image.
>
> But you pay for every module with half a page of unused RAM and module
> code will be in vmalloced memory thus increases TLB pressure a bit.
Even more important, CONFIG_MODULES=y enlarges your kernel image by more
than 5-10%, and you have to make _much_ stuff modular to compensate for
this.
> Regards
> Oliver
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Jun 03, 2008 at 08:19:22PM +0300, Adrian Bunk wrote:
> On Tue, Jun 03, 2008 at 09:54:41AM +0200, Oliver Neukum wrote:
> > Am Dienstag 03 Juni 2008 09:28:59 schrieb Sitsofe Wheeler:
> > > Modules allow you to support more hardware as there is a maximum size of the
> > > core kernel image.
> >
> > But you pay for every module with half a page of unused RAM and module
> > code will be in vmalloced memory thus increases TLB pressure a bit.
>
> Even more important, CONFIG_MODULES=y enlarges your kernel image by more
> than 5-10%, and you have to make _much_ stuff modular to compensate for
> this.
more than 5-10% -> at about 5-10%
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed