[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <g22rrs$6vp$1@ger.gmane.org>
Date: Tue, 03 Jun 2008 08:28:59 +0100
From: Sitsofe Wheeler <sitsofe@...oo.com>
To: linux-kernel@...r.kernel.org
Subject: Re: [Question] about modules/inline benefits
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/
--
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