Subject: Re: kernel symbol tables (was Re: vmstat, iostat etc no longer work?)
To: None <current-users@NetBSD.ORG>
From: Mike Long <firstname.lastname@example.org>
Date: 11/14/1996 14:54:36
>Date: Thu, 14 Nov 1996 03:11:23 EST
>From: Greg Hudson <email@example.com>
>>> 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)
>> 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
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'
3) Can you point us at an example of a "proper LKM interface"?
>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.
Mike Long <firstname.lastname@example.org> <URL:http://www.shore.net/~mikel>
VLSI Design Engineer finger email@example.com for PGP public key
Analog Devices, CPD Division CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA (eq (opinion 'ADI) (opinion 'mike)) -> nil