All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sitsofe Wheeler <sitsofe@yahoo.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [Question] about modules/inline benefits
Date: Tue, 03 Jun 2008 08:28:59 +0100	[thread overview]
Message-ID: <g22rrs$6vp$1@ger.gmane.org> (raw)
In-Reply-To: 4844C4D9.8030502@gawab.com

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/


  reply	other threads:[~2008-06-03  7:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  4:13 [Question] about modules/inline benefits Justin Madru
2008-06-03  7:28 ` Sitsofe Wheeler [this message]
2008-06-03  7:54   ` Oliver Neukum
2008-06-03 17:19     ` Adrian Bunk
2008-06-03 17:27       ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='g22rrs$6vp$1@ger.gmane.org' \
    --to=sitsofe@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.