Robert Elz wrote:
>     Date:        Mon, 20 Feb 2006 14:34:50 +0100
>     From:        joerg@britannica.bec.de
>     Message-ID:  <20060220133450.GB1448@britannica.bec.de>
>
> I'd prefer to keep this topic to the original question, but ...
>
>   | Sorry, this is just bull shit. LKMs add *zero* overhead to the kernel.
>
> Huh?   You mean they don't need any code sitting around occupying
> memory waiting for an LKM to come along to load?   And a call of a
> function in an LKM (from outside, or a different LKM) goes exactly
> as fast as a call of the same function if it is statically linked?
>
> You might not consider the costs significant enough to care about,
> or you might consider the benefits worth the cost, but don't start
> claiming that the cost is zero.
>   
Wow, I didn't think this would be such a hot issue.  LKMs add a small
amount of data (typically detach/unload related logic for drivers that
don't already have it, and a structure with a few new ops), LKM
infrastructure adds a tiny bit (rather like a smallish driver).  The
performance of binary linked vs. static will vary from platform to
platform, but yes, I think generally the benefits outweigh the costs.   IMO.
>   | You have the symbol table in the kernel, as soon as e.g. debugging is
>   | wanted too.
>
> But most people don't want debugging in the kernel.   It crashes,
> I reboot it.   If it happens often, I might send a PR (but it doesn't).
>   
Yes.  And folks who do want it will just rebuild a kernel, because they
are develociraptors. :-)
>   | Proper kernel module support dramatically reduces the need to have
>   | alternative kernels.
>
> Sure, and if you're doing binary distributions that matters.  But
> most of the use of LKMs (with NetBSD) is by people with the sources
> who just don't want to be bothered compiling the kernel they need.
>   
Frankly, configuring a kernel is one of the heartaches that other OS'
long ago realized is something *most* people don't want to do.  Most
folks just want to be able to load a kernel that will do what it will
need to.   And when they buy e.g. a new pcmcia or usb device, they don't
want to have to recompile.

Highly technical users might have fun compiling the kernel, but as *one*
such user, I can tell you that having worked with Solaris' LKM interface
it is *very* nice.  It even has a binary DDI, so I can ship *one* binary
module that works across a Solaris versions going back 5 years or more. 
And I do just that *EVEN FOR MY OPEN SOURCE DRIVERS*.  Why?  Because my
users want to pull down a binary and install it, they don't (usually)
want to recompile the source, even though they can do that from the same
location as the binaries.

There are other reasons that these are attractive for e.g. embedded
system use.  I can have support for a bunch of different devices in my
kernel, but only the ones *in use* would actually be occupying kernel
memory.  In small memory systems this is attractive.
> `
>   | No ACPI subkernels needed, since ACPI is loaded as module
>   | or not, depending on need.
>
> How many times does one of your systems change from needing ACPI
> to not needing ACPI dynamically, while it is running, without
> rebooting it?
>
> kre
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191