>Date: Thu, 14 Nov 1996 03:11:23 EST
>From: Greg Hudson <ghudson@mit.edu>

[I wrote:]
>>> 1) Use kernel symbol table in memory.
>>>    PROS: guaranteed to be correct, can include LKM symbols
>>>    CONS: kernel bloat, bad for low-memory machines (sun3)
>
[cgd wrote:]
>> I would argue that there's a fallacy here.
>
>> Given a proper LKM interface, loadable modules should not need, and
>> should not be given, access to all of the kernel's symbols or the
>> symbols of other modules.
>
>You're Confused (tm).  The argument is that the in-memory symbol table
>could include symbols from LKMs, in addition to the symbols from the
>basic kernel.  I don't really know why this is important, but unless
>I'm completely misunderstanding things, Mike was not arguing that the
>LKM interface could use this symbol table.

Actually, although I never said so, that's what I was hinting at.

But if cgd wants to restrict the visible symbols, my questions for him
are:

1) What criteria divide LKM-visible from LKM-invisible symbols?
2) Where and how is the new module linked against the running kernel?
   From where does modload or ld get the symbols?  (I like Solaris'
   /dev/ksyms, myself.)
3) Can you point us at an example of a "proper LKM interface"?
   Papers? URLs?

>If I'm not calculating wrong, the symbol table on a sample i386 kernel
>is about 52K in size ("ls -l" reports 1023974 bytes, "size" reports a
>dec field of 97171).  Maybe you lose twice that, or 100K, on an Alpha.
>Sure, on a 4MB machine with no swap space, this is going to hurt your
>multi-user performance, but I don't think it's going to make it
>impossible to install the machine, rescue the system, or carry out the
>first part of /etc/rc.
>
>I'm for the more robust approach.  If you're really paranoid about
>that lost memory in the corner cases, there can be both a kernel
>config option and a boot loader option to disable symbol loading.

I agree.
-- 
Mike Long <mike.long@analog.com>     <URL:http://www.shore.net/~mikel>
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil