Subject: Re: IPSEC in GENERIC
To: None <tech-kern@NetBSD.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 02/20/2006 07:50:22
joerg@britannica.bec.de wrote:
> On Mon, Feb 20, 2006 at 08:56:04PM +0700, Robert Elz wrote:
>   
>>   | 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?
>>     
>
> Less than 16kb on ia32. Most network drivers a bigger. Kernel modules are compiled
> the way as normal code, unlike shared objects in userland. E.g. no
> -fPIC. I don't think change of kernel image size counts as overhead and
> otherwise doesn't alter any critical code paths.
>   
making them modules *might* have an impact on cache performance. 
however, since you'd only actually have modules loaded that were
actually being used, it isn't clear what exactly that impact would be.

if you don't have -fPIC (or at least -fpic), how do you get them to be
loadable?  You have to be able to change the addresses, right?  Or am I
missing something obvious?
> That's the wrong question. How many kernels does your live CD / bootable
> USB stick have? Given that a GENERIC kernel is around 8 MB, not having
> two full kernels is a real improvement. A lot of newer machines don't
> boot properly without ACPI and some older machines have problems with
> it, not speaking about APM.
>   
this is the kind of thing I want to avoid -- having different configs
for different hardware that could easily be handled by just having
different drivers loaded seems wasteful to me.

> But back to the original question -- this doesn't affect IPSec at all,
> since it can't be made a module without a lot of efforts in any case.
>   
true, perhaps.  but if so, then why?  it seems a lot of ipsec at least
could be -- e.g. encryption and hash routines, etc.

-- 
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